Pulling balances, card ledgers and SINPE movements out of Banca Móvil BAC

Banca Móvil BAC fronts BAC Credomatic accounts in Guatemala, El Salvador, Honduras, Nicaragua, Costa Rica and Panama — six markets, one app binary, per-country behaviour. The data a third party actually wants sits one authenticated session deep: balances across accounts, cards, savings, loans, pension funds and investments on a single screen, the movement history behind each, and the transfer rails the app drives, including SINPE, ACH and Costa Rica's SINPE Móvil. There is no mandated open-banking scheme in any of those markets to lean on, so reaching that data is an interface-integration problem, run under the account holder's consent and the engaging party's authorization. That is the work this brief describes, and the source code or hosted endpoints we hand back at the end of it.

The honest bottom line: the value here is the per-customer ledger and the movement and transfer feed. Costa Rica runs the region's most mature instant rail, SINPE Móvil, under the central bank, yet there is no finalized cross-bank data-sharing mandate in any of these markets to lean on. So the route we would take is documented interface analysis of the authenticated app session, driven by a consenting account, with native export of receipts and movement proofs as a fallback the app already supports.

What an account exposes

Every row below is a surface the app itself presents, named close to how it labels it. Granularity is what an integrator can expect to read per call, not a guess.

Getting to the data

Three routes genuinely apply here. We set up access for whichever one we run — a consenting account or a sponsor environment is arranged with you during onboarding, not asked of you up front.

Authorized interface and protocol analysis

We analyse the authenticated session the app uses — device registration, login, the BAC Code and token exchange, then the balance and movement calls behind them — and rebuild it as a clean, documented client. This reaches the full surface in the table above, holds across markets with per-country branching, and is the most durable of the three because it follows what the app itself does. Effort is moderate; the variable cost is the front end changing, which the maintenance design handles.

User-consented credential access

Where the engaging party is acting for the account holder, the integration runs against that holder's own credentials with consent recorded. Same reachable data, lighter analysis, but it inherits the device-binding and approval behaviour, so the session design carries more weight.

Native export fallback

The app can resend proof of past movements and share transfer receipts, and BAC runs a parallel web channel at sucursalelectronica.com. Where structured pulls are not yet wired, these give reconciled documents to bridge from. Lowest effort, narrowest surface, useful as a check rather than the spine.

For most engagements the first route carries the integration and the third backs it up: protocol analysis gives the live ledger and rail data, exported proofs give an independent reconciliation point. Which one leads is decided against your actual accounts, not in the abstract.

Session and statement calls, sketched

Illustrative shape, confirmed and pinned during the build against a consenting account. The point is the order — device-bound session first, BAC Code second, then a dated movement query — and the country and currency fields that have to ride along.

POST /auth/device/register        # device bound once, mirrors "Manage the devices you sign in from"
  { "deviceId": "<uuid>", "country": "CR", "channel": "mobile" }

POST /auth/session
  { "user": "<id>", "factor": "BAC_CODE|fingerprint", "deviceId": "<uuid>" }
  -> 200 { "accessToken": "...", "expiresIn": 900, "approvalRequired": false }

GET  /accounts                      # "Balance inquiry" — all products, one call
  -> [ { "productId": "...", "type": "checking|card|loan|savings|investment",
         "currency": "CRC|USD", "balance": 0.00 } ]

GET  /accounts/{id}/movements?from=2026-04-01&to=2026-04-30
  -> { "items": [ { "date": "...", "amount": 0.00, "currency": "CRC",
                    "rail": "INTERNAL|SINPE|ACH|SINPE_MOVIL|KASH",
                    "receiptRef": "...", "retained": false } ],
       "proofResendAvailable": true }

# Error handling that actually occurs here:
#  401 token_expired      -> refresh within expiresIn, do not re-register device
#  409 approval_required  -> surface the transaction-approval step, then retry
#  423 device_unrecognized-> re-run device registration, not a hard failure

What the build hands over

Each deliverable is tied to the surfaces above, not a generic checklist:

• An OpenAPI specification covering the session lifecycle, the consolidated-balance call, dated movement queries, the card ledger, and the transfer/rail feed with rail typing.
• A protocol and auth-flow report: device registration, the BAC Code and token exchange, refresh windows, and the transaction-approval challenge, written as a sequence an engineer can re-implement.
• Runnable source for the key endpoints in Python and Node.js — login, balances, movements with proof reference, card transactions, transfer history — with the per-country branching wired in.
• Automated tests covering token refresh, the approval and device-recognition error paths, and currency handling for colón and US dollar accounts.
• Interface documentation plus data-retention and consent-record guidance matched to how the access was authorized.

What governs this work

Costa Rica is the anchor market and the clearest case. Its instant rail, SINPE Móvil, is operated by the Banco Central de Costa Rica and has run since 2015; Q Costa Rica, reporting central-bank figures, put January–October 2025 SINPE Móvil volume above ¢10.1 billion across more than 615 million transactions, roughly 16.8% up year on year. Supervision sits with SUGEF and the apex council CONASSIF over SUGEF, SUGEVAL, SUGESE and SUPEN. What does not exist yet is a finalized rule compelling a bank to share customer data with a third party: coverage in Costa Rican fintech-law commentary describes an open-banking model still unsettled, with active disagreement between the central bank, SUGEF and the banks over debtor-data access and confidentiality, and a Fintech Framework Bill introduced in July 2024 still in process. Because the rule is in flux, this page states no numeric data-sharing obligation as settled — there is none to state. The other five markets each have their own regulator and bank-secrecy regime, which is why the work runs on documented, account-holder-consented access, with consent records, access logs, data minimization to the fields actually needed, and an NDA where the engagement calls for one.

What the build accounts for

Two things about this app shape the engineering, and we handle both:

• Per-country feature variance. SINPE and SINPE Móvil are Costa Rica only; Kash is enabled in Guatemala, Honduras, El Salvador and Costa Rica; planned savings is absent in Nicaragua; international transfers run only where a contract exists in select markets. We scope the endpoint map by country so a Nicaragua session never calls a savings-goal path that market does not serve, and a non-Costa-Rica session does not expect a SINPE Móvil rail tag.
• Device binding and the approval step. The app manages the devices a customer signs in from and runs in-app transaction approvals alongside the BAC Code and fingerprint entry. We design the session around device registration and the approval challenge so a read integration survives re-authentication, treating an unrecognized-device response as a re-registration path rather than a break. Access — a consenting account or a sponsor environment — is arranged with you during onboarding.
• Dual currency and front-end churn. BAC accounts hold colón and US dollar balances, with an exchange-rate surface in the app, so currency and FX ride on every movement record. The bank ships frequent app updates and the parallel sucursalelectronica.com channel, so we keep a change-detection check on the login and movement responses — a front-end revision shows up as a flagged diff, not a silent data gap.

Where integrators take it

• A regional accounting product reconciling BAC checking and card movements against invoices, separating SINPE Móvil credits from ACH debits by rail tag.
• A lender pulling a consented applicant's balances, loan position and categorized cash flow for affordability assessment.
• A payroll or payout operator confirming third-party BAC and SINPE transfers settled, using the shareable receipt reference as proof.
• A personal-finance app aggregating a household's BAC balances and planned-savings goals beside accounts at other Costa Rican banks.

Keeping the feed honest

A banking front end that ships often is the main durability risk, not the protocol itself. The maintenance design watches the login and movement response shapes and the rail enumeration; when the bank revises the app, the change surfaces as a flagged difference against the pinned contract before it can corrupt a downstream ledger. Movement freshness tracks what the app shows — posted and retained movements as the bank releases them — so the feed does not claim more timeliness than the source has.

The wider Central American banking set

These are real same-category apps an integrator commonly meets alongside Banca Móvil BAC; naming them is ecosystem context for a unified integration, not a ranking. Listed as plain references.

• BN Móvil — Banco Nacional de Costa Rica's app; state-bank accounts, SINPE Móvil and service payments.
• Banca Móvil BCR — Banco de Costa Rica; accounts, cards and PIN/biometric features comparable to BAC's.
• Scotiabank CR Banca Móvil — Scotiabank Costa Rica accounts, cards and transfers.
• Davivienda — the Davivienda Costa Rica app; balances, payments and transfers.
• DaviPlata — Davivienda's wallet; phone-linked balances and point-of-sale payments.
• Promerica Móvil — Banco Promerica de Costa Rica; account management and SINPE Móvil.
• Banco Lafise — regional Lafise group banking across Central America.
• Banco Industrial — Guatemala's largest bank, an in-footprint BAC peer.
• Banco Ficohsa — Honduras retail and card banking.
• Banco Agrícola — El Salvador's largest bank, with a comparable mobile front end.

App screens

The store screenshots, as published, give a read on the surfaces above — the balance screen, movement lists and transfer flows. Select to enlarge.

How this was put together

Built from the app's own published feature list and store identity, BAC Credomatic's corporate history and footprint, and the Costa Rican payment and supervision framework, checked in May 2026. Primary sources opened for this mapping:

• Banco Central de Costa Rica — SINPE Móvil service page
• Chambers — Banking Regulation 2025, Costa Rica
• Lexology — open banking and its implications in Costa Rica
• BAC Credomatic — corporate history and country footprint

OpenBanking Studio · integration desk mapping, May 2026.

Questions integrators ask about Banca Móvil BAC

Can the feed separate SINPE Móvil and ACH transfers from internal BAC-to-BAC movements?

Yes. The Transfers area distinguishes own-account moves, third-party BAC transfers, SINPE and ACH out to other banks, SINPE Móvil in Costa Rica, and Kash sends, and each carries a rail tag and a shareable receipt. We model the rail type and the receipt reference as first-class fields so a downstream system can reconcile a SINPE Móvil credit differently from an ACH debit.

We hold accounts in both Costa Rica and Guatemala — does one integration cover both?

One integration, but the surface is country-scoped. SINPE Móvil and SINPE settlement are Costa Rica only, Kash is enabled in Guatemala, Honduras, El Salvador and Costa Rica, planned savings is absent in Nicaragua, and international transfers run only where a contract exists. We branch the endpoint map by market so a Guatemala session never calls a path that market does not serve.

There is no open-banking mandate in Costa Rica, so what authorizes this work?

The account holder's own consent and a written authorization from the engaging party. Costa Rica has SINPE under the Banco Central de Costa Rica and supervision through SUGEF and CONASSIF, but no finalized data-sharing mandate, so the integration runs on consented credential access and documented interface analysis rather than a regulated AIS scheme, with consent records and access logs kept throughout.

The app does device approval and a BAC Code on transactions — does that block read access?

It shapes the session rather than blocking reads. Balance and movement queries sit behind the device-bound login and the BAC Code, while write actions add a transaction approval step. We design the session around device registration and the approval challenge so a read integration stays stable across re-authentication instead of failing on the first prompt.

Source code for the BAC session, balance and movement endpoints is delivered in one to two weeks and billed from $300, paid after delivery once it works against your accounts. Prefer not to run anything yourself — the same endpoints are available as a hosted pay-per-call API with no upfront fee, you pay only for calls made. Send the app name and what you need from its data at /contact.html and access, authorization and compliance are arranged with you from there.