Scotia GO's account and card data sits behind Chile's open-finance consent — the authorized route in

Behind a Scotiabank Chile login, Scotia GO carries balances and movements across cuentas corrientes, cuentas vista and cuentas de ahorro (rentabilidad diaria), plus credit and debit cards, and the ScotiaPass Digital step that signs off transactions from the phone. Chile now has a named legal channel for moving that data with the customer's consent: the Sistema de Finanzas Abiertas created by Ley Fintech (Law 21.521), supervised by the Comisión para el Mercado Financiero. Scotiabank, as a CMF-supervised bank, is a mandatory information provider under that system. The rule exists; its rollout is staggered and the start date has moved. This brief sets out what the app holds, the route we would take to it today, and what we hand back.

Bottom line: this is a regulated retail-bank app with rich per-customer state and a real consent regime arriving behind it. We would build now against a consenting account through authorized interface integration, modelling Scotia GO's own product taxonomy, and keep the same normalized schema ready to repoint at the SFA endpoints when Scotiabank's first-wave interfaces are live.

What Scotia GO holds for each customer

Each row reflects a surface the app actually exposes to a logged-in Scotiabank Chile customer, named the way the app and Scotiabank's own product pages name it.

Getting at that data without breaking anything

Authorized interface integration against a consenting account

This is the route we recommend to start. We work the app's own client-to-server traffic for a Scotiabank Chile account the client controls, document the auth chain and the movement/statement calls, and build a stable read layer over them. Reachable: every domain in the table above. Effort: moderate — the account taxonomy and the ScotiaPass step are the real work, not the request shapes. Durability: good with a recheck step keyed to Scotiabank releases. We arrange the consenting account and the working environment with you at onboarding.

Sistema de Finanzas Abiertas consent (as it comes online)

Once Scotiabank's SFA information-provider interfaces are live for registered participants, the same customer data moves under an explicit, revocable consent grant supervised by the CMF. Reachable: the account and product information the regime defines. Effort: lower per-call once the consent flow exists; higher right now because the bank-side interfaces are still phasing in. Durability: high — it is a legal channel, not a private one. We track the CMF technical-annex revisions so the schema we ship maps cleanly when Scotiabank's first wave opens.

User-consented credential access

A bridge where a known set of customers explicitly authorize access for their own aggregation. It carries the same data as the first route, scoped to those users, and is useful while SFA participation is still ramping. We handle consent capture and records as part of the build.

Native receipts as a thin fallback

Scotia GO produces comprobantes and card statements the customer can pull. That covers confirmation and document-level needs only, not a live feed. We treat it as a supplement, never the spine.

The recommendation, plainly: build route one now so you have a working feed in weeks, structured so route two is a repoint and not a rewrite.

What lands in your repo

Everything below is tied to Scotia GO's real surfaces, not a generic kit:

• An OpenAPI/Swagger specification covering the account-movement, card-statement, transfer-history and ScotiaPesos endpoints as modelled for this app.
• A protocol and auth-flow report: the login chain, token/session lifetime, and exactly where ScotiaPass Digital injects its approve/reject step.
• Runnable source for the key reads — Python and Node.js — for cuenta corriente / vista / ahorro movements, card statements and transfer comprobantes, returning one normalized schema across product types.
• Automated tests against recorded fixtures, including the multi-currency case where an international card payment carries a non-CLP amount.
• Interface documentation a new engineer can follow, plus consent-record and data-retention guidance aligned to how the SFA expects consent to be logged and revocable.

A statement pull, sketched

Illustrative shapes, confirmed and pinned during the build against a consenting account — field names are normalized, not Scotiabank's wire names:

# Read movements for one Scotia GO product (consented session)
GET /scotia-go/accounts/{accountId}/movements?from=2026-04-01&to=2026-04-30
Authorization: Bearer <session-token>          # short-lived; refreshed on the read path
X-Scotia-Product: cuenta_vista                  # corriente | vista | ahorro | tarjeta

200 OK
{
  "accountId": "cv-***",
  "productType": "cuenta_vista",
  "currency": "CLP",
  "balance": { "available": 184230, "ledger": 184230 },
  "movements": [
    { "postedAt": "2026-04-22T13:04:00-04:00",
      "amount": -45990, "currency": "CLP",
      "description": "PAGO TARJETA CREDITO INTL",
      "fx": { "origCurrency": "USD", "origAmount": -49.90 },   # present only on intl card pay
      "reference": "TX9F2A" }
  ],
  "next": null
}

# ScotiaPass Digital only gates state-changing actions, not this read:
#   if response == 428 -> out-of-band approve required -> surface to the consenting user
#   read flow stays on the pre-step path; sync never auto-approves

Where Chile's Fintech Law puts this

The relevant instrument is Ley Fintech, Law 21.521, which created Chile's Sistema de Finanzas Abiertas, supervised by the Comisión para el Mercado Financiero. As the CMF describes it, banks and credit-card issuers are mandatory information providers and must share customer data with other registered participants only after the customer's explicit prior consent; the regulator has published the governing norm but staged the rollout and deferred the effective start from 2026 to 2027, with banks and card issuers in the first wave and cooperatives, insurers and fund managers following. Because that schedule is still moving, this page does not state its phase windows as settled present-day obligations — what is firm is the shape: consent-based, revocable, CMF-supervised, banks first. For an integrator that means the legal channel for Scotia GO data is real and arriving, and access designed against it should treat consent scope, expiry and revocation as first-class, with consent records kept the way the regime expects. Until Scotiabank's interfaces are live for third parties, we operate under the customer's authorization, log access, minimize what is pulled to the fields in scope, and work under an NDA where the client needs one.

Things we plan around on this build

Concrete points specific to Scotia GO that we account for, so they do not surprise you mid-project:

• ScotiaPass Digital is an out-of-band authorizer, not a password. It replaced the KeyPass app and signs off state-changing actions from the device. We map exactly which calls trigger it so a read sync stays on the pre-challenge path, and we handle the device/enrollment binding with the consenting account during onboarding rather than letting it block the read flow.
• Four product families with different movement shapes. Cuenta corriente, cuenta vista, cuenta de ahorro (rentabilidad diaria) and tarjeta de crédito each carry their own date semantics and balance fields, and international card payments arrive in a foreign currency over a CLP ledger. We normalize all of them into one schema and keep the original currency on the line so treasury reconciliation stays correct.
• ScotiaPass enrollment is a moving front end. Scotiabank rotates that flow, and it changed when KeyPass was retired. We pin the integration to the current ScotiaPass challenge contract and treat an enrollment-screen change as a versioned migration with a recheck step scoped per Scotiabank release — the data schema you build against does not move when the UI does.
• SFA timing is the regulator's, not ours. Because the CMF schedule is staged, we design the read layer so the move from authorized interface integration to SFA consent endpoints is a configuration repoint, not a second project.

Where teams point this integration

• A Chilean personal-finance app aggregating a user's Scotia GO cuenta vista and credit-card movements alongside other banks for a single net-position view.
• An SME treasury tool reconciling a Scotiabank cuenta corriente plus international card payments, with currency preserved per line.
• A lender verifying declared income from cuenta vista movement history under the applicant's explicit consent.
• A loyalty or rewards engine reading the ScotiaPesos balance and redemption ledger to mirror points outside the app.

Cost and how the build runs

A working read layer over Scotia GO's account, card and transfer surfaces is typically a one-to-two-week build. Source-code delivery starts at $300: you receive the runnable source, the OpenAPI spec, the protocol report, tests and interface docs, and you pay after delivery once it works to your satisfaction. The alternative is the pay-per-call hosted API — we run the integration and you pay only for the calls you make, with no upfront fee. Either way the client supplies the app name and what they need from its data; the consenting account, environment and compliance paperwork are arranged with you as part of the engagement. To start or to ask which model fits your volume, contact OpenBanking Studio.

What was checked

This mapping draws on Scotia GO's Play Store listing and Scotiabank Chile's own App Scotia product page for the feature and account taxonomy, and on the CMF's published material on the Sistema de Finanzas Abiertas and its deferred timeline for the regulatory route. Reviewed 2026-05-18 by the OpenBanking Studio integration desk.

• Google Play — App Scotia (cl.scotiabank.go)
• Scotiabank Chile — App Scotia (Scotia GO) product page
• CMF — norm regulating the Sistema de Finanzas Abiertas under Ley Fintech
• CMF (EN) — regulation governing the Open Finance System

Other Chilean apps in the same data conversation

Same market, comparable per-customer state — useful when a project needs more than one institution under one schema. Ecosystem context only, no ranking.

• Banco de Chile app — checking and savings accounts, cards and transfers for one of Chile's largest banks.
• BancoEstado Móvil — state bank with very wide retail reach, CuentaRUT balances and movements.
• Santander Chile — accounts, cards and investments for another major Chilean bank.
• Banco BCI — retail and SME accounts, cards and transfer history.
• Itaú Chile — accounts and cards for the local Itaú franchise.
• Banco Falabella — retail-credit-led accounts and card balances tied to its store ecosystem.
• Coopeuch — savings and credit-cooperative accounts, a CMF-supervised member of the same regime.
• Tenpo — digital account and prepaid card with instant transfers and P2P history.
• MACH — BCI-owned prepaid wallet with balance and transaction records.
• Mercado Pago — wallet balance, transfers and payment history widely used across Chile.

Screens we worked from

Public store screenshots, used to confirm the visible product taxonomy. Select to enlarge.

Questions Scotia GO integrators ask

Can the integration read cuenta vista and cuenta de ahorro movements separately, or only the consolidated home view?

Separately. Scotia GO surfaces cuenta corriente, cuenta vista and cuenta de ahorro (rentabilidad diaria) as distinct products with their own movement lists and date semantics. We model each product type as its own ledger and emit a normalized per-account feed, not just the rolled-up balance the landing screen shows.

How does ScotiaPass Digital change an automated read flow?

ScotiaPass Digital is an out-of-band approve/reject step that replaced the older KeyPass app. Read-only balance and movement calls generally sit before that step; it fires on state-changing actions. We map exactly where the challenge triggers so a data sync stays on the read path and the enrollment binding is handled with the consenting account during onboarding.

Is Chile's Sistema de Finanzas Abiertas usable for this today, or do we go through the app?

The CMF's Open Finance System rule is published but phased, and the regulator deferred its start from 2026 to 2027 with banks and card issuers in the first wave. Until those interfaces are live for third parties, we run the build through authorized interface integration against a consenting Scotiabank Chile account, then move the same normalized schema onto the SFA consent endpoints as Scotiabank exposes them.

If Scotiabank changes the ScotiaPass enrollment screen mid-project, what happens to our integration?

We pin the integration to the current ScotiaPass challenge contract and treat an enrollment-flow change as a versioned migration rather than a silent break, with a recheck step scoped per Scotiabank release. The data schema you build against does not move when the front end does.