Moja mBanka Raiffeisen — pulling iRačun, IPS QR, FX and SEF flows out of the app

Raiffeisen banka a.d. Beograd lit up its mobile front door — Moja mBanka Raiffeisen, package rs.Raiffeisen.mobile on Google Play, store id 1053503191 on iOS — at the same moment Serbia's payment-services framework finally caught up with PSD2. As of the NBS Regulatory Technical Standards extension, banks here have until 1 January 2026 to ship the open-banking surfaces, which means right now is the sweet spot for batch-ingesting historical iRačun activity, IPS QR payments and SEF e-invoices into your own systems before everyone else queues up against the new rails. Per the app's Play Store and Apple App Store listings; version strings are not stated bare here because they roll fortnightly.

The bottom line: the data this app carries is rich enough to feed AP/AR automation, treasury reporting and personal-finance aggregation, and the route is no longer purely interface-level — Serbia's amended Law on Payment Services now permits Account Information Service Providers and Payment Initiation Service Providers, with Berlin-Group NextGenPSD2 as the de facto shape. The recommended spine for a first delivery is a batch backfill of dinar and FX statements behind a Berlin-Group-style consent, with the protocol-capture path kept as a fallback for any surface the bank has not exposed to AIS by the time you ship.

Data the app holds, and where each row originates

The rows below come from a read of the app description, the bank's own help knowledge base, and the screenshots on the store listings. Every domain corresponds to a surface a user can see in the app today.

Routes to the data

Three are live for this app today; one is a fallback that earns its keep where the bank has not yet exposed a surface to AIS.

1. Regulated AIS / PIS under the amended Serbian Law on Payment Services

Since 6 May 2025 the amended PSA permits AISPs and PISPs to operate against Serbian payment-account providers, and the NBS extended the technical compliance deadline to 1 January 2026 so every relevant bank, Raiffeisen included, has shipped a contract-style API for account information and payment initiation. The contract follows Berlin Group NextGenPSD2; consents run up to 90 days; the bank requires an eIDAS QWAC for the live channel. Durable, scoped to dinar and FX payment accounts.

2. Authorised interface integration / documented protocol analysis

For the surfaces that are not (yet) covered by the AIS contract — SEF e-invoice status writeback, Mobile Cash event timing, "Online Offer" submissions, the Inbox message stream — the studio captures the app's own traffic against an account the customer authorises, derives the request and response shapes, and ships a client that speaks the same protocol. Compliance-first: documented, logged, consented, NDA where the engagement needs one. This is how we cover Business iRačun automation that the AIS contract has not formalised.

3. User-consented credential access

Where a customer wants to integrate against a single account they own (typical for a sole-trader doing their own AP automation), the build runs through the in-app login flow on the customer's behalf with their explicit, logged consent, and stores nothing beyond the refresh token. Lightest setup; less durable across app upgrades; useful as a stopgap until route 1 covers the surface.

4. Native CSV / SWIFT-statement download

The Business mBanka surface already exports per-account turnover and statements in CSV and SWIFT MT940 shapes, and the personal app lets the customer request signed statements through the Inbox. Slowest cadence, but a useful reconciliation baseline against routes 1–2; we wire it as the integrity check, not the spine.

For a first delivery against this app we lead on route 1 — Berlin-Group AIS over the bank's live channel, batch-backfilled — and back it with route 2 for SEF e-invoice writeback and Mobile Cash, because those two surfaces are where the AIS contract is least mature so far and where the customer's actual ledger needs movement.

Shape of a call against this app

Illustrative only; the live endpoints, header names and exact field shapes are confirmed during the build against the bank's developer materials and a documented capture of the app under a consented account.

# Authorized read of iRačun activity for a consented dinar account.
# Contract follows the Berlin Group NextGenPSD2 framework that the NBS
# Regulatory Technical Standards lean on. Consent is issued once per
# user, valid up to 90 days, then renewed ahead of expiry by the
# scheduler — never as a silent retry on the read path.

from datetime import date, timedelta
import httpx, uuid

class RaiffeisenAis:
    BASE = "https://psd2.raiffeisenbank.rs/v1"   # confirmed during build

    def __init__(self, consent_id: str, bearer: str, qwac: tuple):
        self.consent_id = consent_id
        self.bearer = bearer
        self.qwac = qwac                          # eIDAS cert + key

    def list_iracun_transactions(self, iban: str, days: int = 30):
        params = {
            "dateFrom": (date.today() - timedelta(days=days)).isoformat(),
            "dateTo":   date.today().isoformat(),
            "bookingStatus": "booked",            # 'pending' is a separate sweep
        }
        r = httpx.get(
            f"{self.BASE}/accounts/{iban}/transactions",
            params=params,
            cert=self.qwac,
            headers={
                "Authorization":  f"Bearer {self.bearer}",
                "Consent-ID":     self.consent_id,
                "X-Request-ID":   str(uuid.uuid4()),
                "PSU-IP-Address": "203.0.113.7",
            },
            timeout=20.0,
        )
        r.raise_for_status()
        page = r.json()["transactions"]
        return page["booked"], page.get("_links", {}).get("next")

# IPS QR payload (NBS standardised string, decoded for downstream use).
# Captured from the app's own QR-pay surface and from SEF-routed bills.
ips_qr_fields = {
    "K":  "PR",                       # consumer payment marker
    "V":  "01",                       # version
    "C":  "1",                        # charset code (UTF-8)
    "R":  "RS35160005400000123456",   # recipient account
    "N":  "Raiffeisen banka a.d.",    # recipient name
    "I":  "RSD1234,56",               # currency + decimal-comma amount
    "SF": "189",                      # transaction code
    "RO": "97 84 0123456789",         # model + structured reference
}

What ships at the end

The deliverable leans toward code that runs against the customer's own stack, with the paper trail attached where regulators or auditors will eventually ask for it.

• Runnable client source in Python and Node.js, structured as a small SDK rather than a one-off script: account, card, statement, IPS QR and SEF endpoints, with retry, paging and Consent-ID handling already wired.
• A batch backfill runner that pulls the historical iRačun and Business iRačun statements in dated windows, keyed on the bank-side transaction identifier so a re-run after an outage fills the gap without booking the same line twice.
• An ingestion-side reconciler that compares the AIS-route reads against the native CSV / MT940 statement exports on a slower cadence — the integrity check that catches a missed booking before the customer notices.
• A webhook surface for the customer's downstream services: signed event envelopes carrying booked transactions, IPS QR settlements and SEF status transitions, keyed on the bank-side reference so the receiver knows what to do on replay.
• Automated tests against a sponsor sandbox where one is on offer, and against a recorded fixture set otherwise, so a bank-side endpoint rename or field-name change trips the fixture before it reaches the customer's reconciliation step.
• OpenAPI specification, an auth-flow report covering the QWAC handshake and consent lifecycle, and an interface document the customer's internal audit can read without help.

Consent and the NBS rules

The supervising regulator is Narodna banka Srbije. The instrument is the recent amendment to the Law on Payment Services (in force from 6 May 2025) that introduced PIS and AIS as licensed services and shifted the bank-side compliance bar to 1 January 2026 under the published NBS Regulatory Technical Standards. Consent is per-user, per-account, scoped (balances and transactions are separate scopes from payment initiation), and runs up to 90 days before requiring a fresh strong-authentication step. eIDAS QWAC is the certificate type the bank's live channel expects on the AIS side. Data minimisation is enforced at the consent scope, not by the integrator — only the rows the user agreed to are returned. Where a deployment will touch personal data, the engagement includes a short data-flow note for the customer's DPO to keep on file; where an NDA is needed (typical for the protocol-analysis path) we sign one. Nothing about this is exotic; it is the same Berlin-Group posture Austrian and Hungarian RBI entities have been running for years, with the Serbian RTS gluing it into place.

Things the build accounts for

These are the app-specific decisions the build makes for the customer, not preconditions on the customer side. Access, sponsor sandbox if one is needed, and the QWAC trust are arranged with the bank as part of onboarding.

• 90-day consent renewal. The NBS RTS caps an AIS consent at 90 days. The scheduler refreshes the token at day 85, surfaces a re-authentication prompt to the user only when the bank requires a fresh SCA step, and never lets a statement sweep run with an expired token — without that, the third-month sweep returns a 401 from the bank and the customer's dashboard sits stale until someone notices.
• RSD 300,000 IPS ceiling. Individual IPS transfers are capped at this amount by NBS. The build splits a larger settlement file at the ceiling, routes the remainder over RTGS, and reconciles both confirmations back into a single payment-batch identifier so the customer's reconciliation does not see two unrelated payments where it expected one.
• Two profiles inside one brand. "Moja mBanka" and "Moja mBanka Biznis" are distinct flows with distinct consent envelopes — personal iRačun on one side, dinar Business iRačun + FX inbound + FX purchase + sick-leave account on the other. We model them as two clients sharing a token store, not as one ambiguous profile, so SEF reconciliation pulls against the right legal entity.
• Digital + standard-format cards. iRačun issues both a digital card usable immediately in the app and a physical card mailed to the customer. The build tracks card lifecycle events per token (issued, activated, temporarily blocked, unblocked) so a digital-only token never reads as a missing physical card and vice versa.
• SEF API-key custody. The SEF integration on the app side asks the customer to paste an API key generated at efaktura.mfin.gov.rs. The build keeps that key in the customer's secret store, not ours; the bank-side consent and the SEF-side authorisation are two separate trusts and we never collapse them.
• Decimal-comma locale. RSD amounts come back with a decimal comma in some surfaces (the IPS QR string, signed PDF statements) and a decimal point in others (the JSON transactions feed). The SDK normalises to a single integer-minor-unit representation at the edge, so downstream code never has to worry about which surface the number came from.

Interface evidence

Screenshots from the Play Store listing — the home screen, IPS QR pay, FX, card management, Mobile Cash and the Business surface. Click to enlarge.

What we checked, and where

The app description and Play Store listing, the bank's own product pages for personal m-banking and small-business m-banking, the Raiffeisen knowledge base entry on e-Fakture / SEF integration, the National Bank of Serbia's published IPS QR specification, and the NBS RTS extension notice that sets the 1 January 2026 compliance deadline.

• Raiffeisen banka — Moja mBanka product page (retail)
• Raiffeisen knowledge base — e-Fakture / SEF integration inside Moja mBanka Biznis
• NBS — IPS QR code generator/validator specification (PDF)
• NBS publishes RTS and extends PSD2 compliance deadline to 1 January 2026

OpenFinance Lab — assessment, 31 May 2026.

Questions integrators tend to ask

Once the user-consent window expires, how does the build keep the statement feed warm?

Under the NBS Regulatory Technical Standards a consent for account information runs up to 90 days. The build refreshes the consent token from a scheduled job several days ahead of expiry, with the user prompted in-app only when the bank requires a fresh strong-authentication step. Between renewals, transaction pulls run as a paged backfill against the consented IBAN so a missed day is recoverable on the next sweep.

What happens if a payment we route exceeds the IPS RSD 300,000 ceiling?

The instant-payment rail caps individual IPS transfers at RSD 300,000. The build splits a larger payment file at that ceiling: transfers under the cap are sent over IPS for second-level settlement, the remainder is routed over the standard RTGS clearing rail, and the resulting two confirmations are reconciled back into a single payment-batch identifier so the caller sees one logical settlement.

Does the integration reach the Business mBanka SEF e-invoice surface as well as personal iRačun?

Yes. The retail iRačun statement, card and Mobile Cash flows and the Business e-Fakture surface are two distinct profiles inside the same app brand. Each profile has its own consent and its own legal-entity scope, so a customer doing AP automation gets the SEF invoice list plus the dinar Business iRačun turnover wired together, while a personal-finance use case stays scoped to the retail account.

Is this tied to Raiffeisen banka a.d. Beograd specifically, or does the same pattern reach the wider Raiffeisen Group?

This page is about the Serbian entity, Raiffeisen banka a.d. Beograd, supervised by the National Bank of Serbia. The parent group (Raiffeisen Bank International) covers its Austrian and CEE entities under separate Berlin-Group NextGenPSD2 arrangements; each is a separate engagement against a different jurisdiction. The Serbian rails follow the same Berlin-Group shape under the NBS RTS, which is why the same client code generalises with light per-entity configuration.

Other Serbian banking apps in the same orbit

Same-jurisdiction apps a customer building a Serbian-banking aggregator usually wants in the same engagement. Plain names; no ranking is implied.

• Banca Intesa Mobi — Intesa Sanpaolo's Serbian arm; largest bank in the country by market share and a near-identical IPS QR / SEF posture.
• OTP mBanking (OTP banka Srbija) — OTP Group Serbia, post-merger with Vojvođanska, similar retail and SME data surfaces.
• UniCredit Mobile B@nking Srbija — UniCredit's local entity; the Business profile carries the same SWIFT / Loro / FX patterns.
• Erste mBanking Srbija — Erste Group Serbia; SEF e-invoice wiring and IPS QR collection follow the NBS standard.
• AIK Mobi Banka — AIK banka, the largest domestic-capital lender in the top five.
• NLB Komercijalna mKlik — NLB Group Serbia (formerly Komercijalna banka), broad retail footprint, full IPS QR.
• Yettel Bank — digital-first issuer; lighter on Business surfaces, denser on personal-finance data domains.
• ProCredit M-Banking — ProCredit Bank's Serbian app, SME-leaning.
• Postbank Mobile — Banka Poštanska štedionica, broad retail reach and the post-office channel.
• RaiPay — Raiffeisen banka's companion wallet app; complements Moja mBanka for tap-to-pay flows.

Working with us

The price starts at $300 for source-code delivery against this app, paid after we hand over the working client and you have it running against your own account. If you would rather we host the endpoints and bill per call, that model is available with no upfront fee. A first delivery — runnable SDK, batch backfill of iRačun and Business iRačun statements, IPS QR event handler, SEF invoice reader, automated tests and the OpenAPI spec — runs in one to two weeks from a green-lit start. Tell us the app you want reached and what shape you need the data in; access, QWAC trust and any sandbox onboarding are arranged with you and the bank as part of the build. Start an engagement →