Integrating Mi Banco while Chile's open-finance clock keeps slipping

Data Mi Banco keeps server-side

Reaching Banco de Chile's account data

Three routes genuinely apply here; one carries the work today and one is the destination.

User-consented interface analysis

With a consenting account holder, we capture and document the authenticated Mi Banco session — the RUT-plus-MI-PIN enrollment, the device binding, the token it issues, and the balance, movements and card calls behind it. Every read surface in the table is reachable this way. Transfers and bill payments are reachable too, but they cross Mi Pass authorization, which we document rather than work around. Effort is moderate; durability means a re-validation pass when Banco de Chile changes the app front end. The consenting test account and enrolled device are arranged with you during onboarding — that setup is our step, not a hurdle put in front of you.

Regulated sharing through the SFA

As Banco de Chile exposes its Sistema de Finanzas Abiertas information APIs under the CMF's NCG 514, consented data sharing runs through standardized OAuth2 and PKI interfaces — enrollment, balances, transactional history and product data, with consent recorded centrally. Long-run effort is lower and durability is high once the endpoints are live, but the timing rides the CMF calendar, which has been put out for revision. We track the directory and keep the same normalized schema ready to point at it.

Statement export as a stopgap

Where the account holder can pull a cartola or PDF statement, we parse those for history while a live integration is being built. It is point-in-time and narrow, useful only as a bridge.

For most teams the sensible build is the consented interface route now, with the data model written so the SFA endpoints drop straight in when Banco de Chile publishes them. That keeps you live this quarter without throwing the work away later.

A balance-and-movements pull, sketched

Shapes below are illustrative and get pinned to the exact field names and error codes during the build, against a consenting account.

# 1. Device-bound login: RUT + 5-digit MI PIN on an enrolled device
POST /auth/session
  { "rut": "<account-holder RUT>", "miPin": "<5 digits>",
    "deviceId": "<enrolled device fingerprint>" }
-> 200 { "accessToken": "...", "expiresIn": 900, "refresh": "..." }

# 2. Accounts the customer can see
GET /accounts            Authorization: Bearer <accessToken>
-> 200 [ { "accountId": "CC-001", "type": "cuenta_corriente",
           "saldoDisponible": 482350, "saldoContable": 482350,
           "currency": "CLP" } ]

# 3. Movements for one account, paged
GET /accounts/CC-001/movimientos?from=2026-04-01&to=2026-04-30&page=1
-> 200 { "items": [ { "fecha": "2026-04-12", "glosa": "PAGO CUENTA LUZ",
           "monto": -28940, "tipo": "cargo" } ],
         "nextPage": 2 }

# Error handling the client must carry
#   401 token_expired      -> refresh, retry once
#   401 pin_reauth_required -> session bound to device; prompt re-enroll flow
#   409 mi_pass_required    -> write/transfer path: hand off to Mi Pass
#                              authorization, do not retry the read loop

What lands in your repository

The deliverable is built around the surfaces above, not a generic kit:

• An OpenAPI specification covering accounts, balances, movements, card and credit-line reads, and the transfer / pago-de-cuentas write flow with its Mi Pass step marked.
• A protocol and auth-flow report: RUT-plus-MI-PIN enrollment, device binding, token issue and refresh, and precisely where Mi Pass or DigiPass gates a write.
• Runnable client source in Python and Node.js for the read endpoints, with the session-refresh logic wired in.
• Automated tests — token refresh, movement pagination, balance reconciliation, and the Mi-Pass-required branch on a write call.
• Interface documentation a back-end team can hand to maintenance.
• Consent and data-retention guidance written against Ley Fintec and CMF expectations.

Where teams wire this in

• A Chilean personal-finance app folding a Mi Banco balance and cash-flow view in next to BancoEstado and Santander accounts.
• An SME bookkeeping tool pulling movimientos nightly so reconciliation is done before the owner opens the ledger.
• A lender reading a consented twelve-month movement history for an affordability check, then discarding the raw feed.
• A payouts product disbursing through card-free ATM codes to recipients with no card — a write path, designed around Mi Pass authorization.

Ley Fintec, the SFA, and where consent sits

Chile's Ley Fintec (Law 21,521, published January 2023 per the official gazette) created the Sistema de Finanzas Abiertas, supervised by the Comisión para el Mercado Financiero (CMF) and set out in Norma de Carácter General N° 514, issued July 2024. Sharing under it is conditioned on the account holder's explicit, revocable consent, with data minimization built in. The rollout is phased over several years, and the precise milestones are themselves being reworked: the CMF has placed a roughly twelve-month postponement of the system's entry into force out for public consultation, so the specific obligation dates are not settled and are not asserted here as fixed. Until Banco de Chile's SFA endpoints are live, the consented interface route runs under the account holder's documented authorization — consent records and access logs kept, data minimized to what the use case needs, NDA in place where the engagement calls for it. That is how the studio operates, not a gate you clear before we begin.

Engineering details this build plans around

Four things we account for and handle on Mi Banco specifically:

• MI PIN is device-bound. First registration binds the PIN to a device. We run the integration from an enrolled, consenting device and carry the PIN-based session refresh so the sync does not silently drop when the short-lived token expires.
• Mi Pass and DigiPass gate writes, not reads. We scope the read-only sync so it never trips a step-up it does not need, and we document the exact point where a transfer, card-free code or pago de cuentas hands off to Mi Pass, so a payments use case is designed around the holder's consent from the start.
• Sibling apps share the model, not the back end. Banco de Chile also ships Mi Banco Edwards (Banco Edwards) and Mi Banco CrediChile on the same family. We confirm the target account's entity and segment so the integration hits the right host.
• Forward-compatibility with the SFA. We shape the normalized schema to map onto the SFA information APIs, so the near-term build carries over when the CMF calendar lands and Banco de Chile publishes its endpoints.

Screens this mapping was checked against

Store screenshots used while mapping the surfaces above. Select to enlarge.

What was checked, and when

Reviewed in May 2026. We read the Mi Banco store listing for the data the app surfaces and its login model, the CMF's own announcements for the Sistema de Finanzas Abiertas regulation and the consultation that postpones it, and the text of Ley 21,521 for the consent framework. Primary sources opened:

• Mi Banco — Google Play listing (cl.bancochile.mi_banco)
• CMF — regulation of the Sistema de Finanzas Abiertas under the Ley Fintec
• CMF — amendments to NCG 514 placed out for public consultation (postponement)
• Ley Chile — Law 21,521 (Ley Fintec) full text

Compiled by the OpenBanking Studio integration desk — assessment dated May 2026.

Other Chilean apps in the same data space

The data sources a unified Chilean account view would normalize alongside Mi Banco, named for context, not ranked:

• BancoEstado — the state-owned bank's app, holding CuentaRUT balances, transfers and bill payments for a very large user base.
• Santander Chile — account balances, credit cards and transfers in-app; a frequent counterparty in any cross-bank aggregation.
• Banco BCI — accounts, cards and transfers; BCI also operates the MACH wallet.
• MACH — BCI-owned prepaid wallet and account: top-ups, P2P transfers and card spend without a traditional bank account.
• Tenpo — digital prepaid account and card with balances, transfers and card transactions held server-side.
• Banco Falabella — retail-bank app covering accounts, CMR-linked cards and statements.
• Scotiabank Chile — the ScotiaZero digital account, cards and transfers exposed in-app.
• Itaú Chile — Itaú's app and the Itú neobank account surface balances, cards and transfers.
• Banco BICE — accounts, cards and transfers, positioned toward higher-segment customers.

Questions Banco de Chile integrators raise

Does pulling balances and movements trigger a Mi Pass or DigiPass prompt?

Generally no. A read-only sync from an enrolled, consenting account reads saldos and movimientos without a step-up. Mi Pass and DigiPass gate transaction authorization — transfers, card payments, bill pay — not balance reads, and we document exactly where a write flow crosses that line.

Mi Banco, Mi Banco Edwards, Mi Banco CrediChile — which one does this cover?

Banco de Chile ships sibling apps on the same family. The data model is shared but enrollment and the back end differ by entity and segment, so we confirm which one the target account belongs to and point the integration at the right one.

Should we wait for the Ley Fintec SFA APIs instead of building now?

The SFA entry into force has been put back — the CMF placed a roughly twelve-month postponement out for public consultation. A near-term build runs on user-consented interface analysis, and we shape the schema so it maps onto the SFA information APIs when Banco de Chile's endpoints publish, so the work carries over.

Can the integration also send a transfer or pay a utility bill, not just read?

Yes. Transfers, card-free ATM withdrawal codes and pago de cuentas are reachable, but those write flows go through Mi Pass authorization by design. We build the payment path around the account holder's consent and keep it separate from the read-only sync.

Starting a Mi Banco build

A Mi Banco integration is a one-to-two-week piece of work. We deliver the runnable source for the balances, movements and card endpoints plus the auth-flow report from $300, invoiced only after you have it in hand and are satisfied; if you would rather not run anything yourself, the same integration is available as a hosted API you pay per call, with nothing upfront. You give us the account segment and what you need out of the data — access, the consenting test account and any compliance paperwork are arranged with you as part of the work. Start the conversation at /contact.html.