Pulling DailyFin's card, deposit and loan records into your own systems

Belarus's National Bank made open-banking API support mandatory for the country's banks, and the standard it published — Payment API Standard 6.02-1-2022 — leans toward payment initiation. The card, deposit, loan and statement records a Belgazprombank customer reads inside DailyFin sit behind an MSI-backed login in the app itself. That gap between a payment-led regulated layer and a rich authenticated client is the whole shape of this integration, and it decides which route is worth running.

Bottom line: the records a third party would want — per-card state, deposit balances, the loan's outstanding debt and minimum payment, dated statements, the several currency-rate planes — all originate in the authenticated DailyFin client, not in the narrow account-information slice the national standard covers in practice. The route that actually reaches them is authorized analysis of the app's own traffic with the account holder consenting. The regulated Open API is real and worth using where the job is payment initiation; it is not the path to a customer's full DailyFin ledger today.

What DailyFin keeps on Belgazprombank's servers

Domains below are named the way DailyFin and the bank's help pages name them. Each row is a surface we have seen in the app description and the Belgazprombank DailyFin help material, not a generic banking checklist.

Routes into the data, and the one we'd run

Four routes genuinely apply here. They differ in reach, effort and how long they last before a DailyFin release moves something.

1. Authorized interface integration of DailyFin traffic

Analysis of the app's own protocol under the account holder's consent. This reaches everything in the table — cards, deposits, loans, statements, FX, ERIP, transfers — because it works against the same surface the customer uses. Effort is moderate; durability is good with a per-release re-check. Access and the consenting account are arranged with you during onboarding; the build runs against that account or a sponsor sandbox. This is the route we would actually run for the full ledger.

2. The National Bank's regulated Open API

Payment API Standard 6.02-1-2022 is mandated for Belarusian banks and defines processes for obtaining account information and initiating payments. In practice the standard is payment-initiation-led and account-information adoption across the market is still limited, so we use this where payment initiation or the narrow account-info endpoints are the job, and layer it onto route 1 rather than treating it as the data path.

3. User-consented MSI session

Where the customer holds the consenting account, the MSI activation flow itself — access code plus SMS code, optionally biometric — is the basis for a consented session. Lowest friction when the account is in hand; scoped tightly to that holder.

4. Native statement export

DailyFin generates statements across account types, and the BGPB family can save or send a generated statement. A serviceable low-frequency fallback for accounting ingestion when a live sync is not needed.

For a third party that needs the customer's actual DailyFin position, route 1 carries the build and route 2 is folded in only when payments must be initiated through the regulated rails. Routes 3 and 4 are situational and we say so up front.

A statement pull, sketched

Illustrative only — field names and the exact session bootstrap are confirmed during the build against a consenting account. It shows the shape: an MSI-style session, then a dated statement query across one account.

# DailyFin — consented statement pull (illustrative)
session = msi_bootstrap(
    msisdn      = "+375XXXXXXXXX",
    access_code = "******",          # 6-digit code set by the holder
    sms_otp     = "********",         # 8-digit activation code via SMS
)

resp = client.get(
    "/v1/accounts/{account_id}/statement",
    params = {
        "account_id": acc.id,         # current | credit | deposit | basic
        "from": "2026-04-01",
        "to":   "2026-04-30",
        "currency": "BYN",
    },
    headers = {"Authorization": f"Bearer {session.token}"},
)

# Expected, normalized at handover:
# { "account_id", "type", "opening_balance", "closing_balance",
#   "currency", "operations": [
#     { "ts", "amount", "direction", "counterparty",
#       "category", "erip_biller_id?" } ] }

if resp.status == 401:        # token aged out — MSI re-bootstrap
    session = msi_bootstrap(...)
elif resp.status == 423:      # holder block / limit guard hit
    raise StatementLocked(acc.id)
      

What you get at handover

Deliverables are tied to DailyFin's real surfaces, not a template list:

• An OpenAPI/Swagger specification for the mapped DailyFin surfaces — cards, statements, deposits, loans, FX planes, ERIP, IPS transfers.
• A protocol and auth-flow report covering the MSI activation handshake, the access-code and SMS steps, token refresh, and session pinning against the shared BGPB back end.
• Runnable source in Python or Node.js for the key endpoints, with the statement, card and ERIP catalog calls working end to end.
• Automated tests run against a consenting account or sponsor sandbox.
• Interface documentation a developer can act on without us in the room.
• Data-retention and consent-logging guidance written for Belarusian law and the MSI consent model.

The National Bank's Open API, MSI, and consent here

The regulator is the National Bank of the Republic of Belarus. Its Payment API Standard 6.02-1-2022, "Banking. Information Technology. Open banking APIs. Payment APIs. Specification", is published as a legislative act and binds banks, non-bank credit and financial organizations, the Development Bank of the Republic of Belarus and the Belarusian Currency and Stock Exchange as API suppliers and users. Identity runs through MSI, the Interbank Identification System, a state remote-identification layer organized on the ERIP settlement space; rules for handling MSI client data were set at Council of Ministers level, reported in 2021, and biometric means (fingerprint, face) are recognized alongside the access code. Consent in this model is bound to the named account holder and is revocable; the studio works only with authorized or user-consented access, keeps access and consent logs, minimizes the fields pulled to what the integration needs, and signs an NDA where the engagement calls for one. This is how we operate, not a gate the reader has to clear before we start.

Things this particular build has to get right

These are specifics we account for and handle, drawn from how DailyFin actually behaves:

• MSI bootstrap produces a six-digit access code and an eight-digit SMS activation code per the bank's help pages. We model that two-factor handshake and the SMS step so the session and its token lifecycle are reproducible against a consenting account.
• DailyFin shares a back end with BGPB mobile and BGPB Business. We pin the integration to the DailyFin client surface and design for the case where the holder also logs in from BGPB mobile, so a parallel session does not silently invalidate the sync.
• Currency data has several rate planes — card and ATM cash, non-cash, NBRB reference, plus the Converter. We normalize them into one rate object with the plane labelled, rather than flattening them into a single misleading number.
• The ERIP biller tree is large and changes. We snapshot the relevant Calculation branch and re-pull it on a schedule instead of hardcoding billers, and we re-check the captured flows on each DailyFin release across the BGPB family.

Three jobs this integration would do

• A Belarusian accounting service ingests dated DailyFin statements across an SME owner's credit, current and deposit accounts and reconciles them against bookkeeping.
• A treasury tool syncs deposit and loan balances and the labelled FX rate planes, so a finance team sees position and the cost of a conversion without opening the app.
• A payout product issues Instant Payment System transfers by recipient phone number and automates recurring ERIP bills from the Favorites and Autopayment surfaces.

Screens we mapped

Public store imagery, used to confirm the surfaces above. Select to enlarge.

How this brief came together

Checked in May 2026 against Belgazprombank's own DailyFin help pages, the National Bank of the Republic of Belarus open-API material, the ERIP/MSI operator pages, and the open-banking tracker entry for Belarus. Primary sources: Belgazprombank DailyFin help, National Bank — open API development, ERIP — MSI (Interbank Identification System), Open Banking Tracker — Belarus.

OpenBanking Studio integration desk · DailyFin surface mapping reviewed 2026-05-16.

Other Belarusian finance apps in the same picture

A unified integration over Belarusian banking rarely stops at one app. Neutral context, not a ranking:

• M-Belarusbank — Belarusbank's retail app; large card, deposit and ERIP footprint nationwide.
• Insync (INSNC) — Alfa Bank Belarus mobile banking; cards, transfers and payments behind an authenticated account.
• Oplati (Оплати) — Belinvestbank's QR-payment and chat-transfer app built around ERIP and Belkart.
• Belkart Pay — wallet for the Belkart national card scheme with the widest partner-bank reach.
• A1 Banking — banking app from the operator A1; remote account and payment services.
• BGPB mobile — Belgazprombank's classic mobile bank; same back end as DailyFin, different client surface.
• Prior Online — Priorbank's app; accounts, cards and transfers for a major Belarusian bank.
• Belagroprombank internet banking — accounts and payments for one of the country's largest banks.
• Myfin.by — a comparison platform listing exchange rates, deposits and loans across Belarusian banks.

What a DailyFin integrator usually asks

Does DailyFin's MSI login block an authorized integration?

No. MSI is Belarus's Interbank Identification System — a state remote-identification layer built on the ERIP settlement space. DailyFin bootstraps a session from it with a six-digit access code and an eight-digit SMS activation code, per Belgazprombank's own help pages. We model that handshake against a consenting account so the session and token lifecycle are reproducible; the login is a step we engineer around, not a wall.

Can the National Bank's Open API standard reach DailyFin balances and statements directly?

Belarus's Payment API Standard 6.02-1-2022 is mandated by the National Bank but leans toward payment initiation, and account-information coverage across Belarusian banks is still thin in practice. So for the card, deposit, loan and statement records DailyFin shows, the route we actually run is authorized interface integration of the app's own traffic under the account holder's consent, with the regulated Open API layered in where payment initiation is in scope.

How do you handle the ERIP biller tree and Instant Payment System transfers?

ERIP — the National Bank's settlement space, shown in DailyFin as the Calculation service tree — is mapped as its own catalog surface, snapshotted and re-pulled on a schedule rather than hardcoded, because the biller branches change. Instant Payment System transfers, which use the recipient's phone number as the identifier, are mapped as a separate payout endpoint with their own status model.

Will the integration survive a DailyFin app release, and how fast is the first build?

DailyFin shares a back end with BGPB mobile and BGPB Business, so a release on any of them can shift the surface. Each release is re-checked against the captured flows and you get a refreshed spec. The initial build runs in a one-to-two-week cycle.

Runnable source for the DailyFin surfaces above is delivered in Python or Node.js, from $300, and you pay only after handover once it works the way you need it to; or skip the build entirely and call our hosted endpoints, paying per call with nothing upfront. Tell us the app and what you want from its data at /contact.html — the consenting-account access and the MSI and consent paperwork are arranged with you from there.