Integrating Scotia Caribbean across seven Caribbean markets

Seven country backends sit behind a single Scotiabank-issued app — Jamaica, Trinidad and Tobago, Barbados, the Bahamas, the Dominican Republic, the Turks and Caicos, and the Cayman Islands — and each one carries the customer's authenticated portfolio in slightly different shape. The Scotia Caribbean mobile front end (package com.scotiabank.cca.mobile, per its Play Store listing) is the practical entry point. The integration question is not whether to read the data; it is how to read it consistently across seven supervisory jurisdictions without breaking the consent shape any of them expect.

Three things matter for an integrator. First, the data is rich and authenticated — balances, full transaction history, downloadable statements, recipients and payees, card-control state. Second, the consent model is per-customer and per-country, not per-region. Third, retention in the app itself is bounded, so a useful integration is a sync, not a one-shot pull.

Data the app actually holds

Where consent and regulation sit, market by market

There is no single Caribbean open-banking statute to lean on. Each Scotia Caribbean account sits with a separately licensed Scotiabank subsidiary, supervised by that country's central bank or monetary authority: Bank of Jamaica, Central Bank of Trinidad and Tobago, Central Bank of Barbados, Central Bank of The Bahamas, Cayman Islands Monetary Authority, and the Banco Central de la República Dominicana, with the Turks and Caicos Financial Services Commission alongside. The Bank of Jamaica runs the most visible fintech track in the region — a FinTech Regulatory Sandbox in effect since 16 March 2020, with updated guidelines published in October 2024 — but that is a sandbox for novel digital-finance entrants, not a customer-data-rights regime.

The practical implication is that the dependable basis for an integration is the customer's own written authorization, scoped to specific accounts and data fields, dated, retained alongside the integration logs, and revocable. Where a build needs to talk to two or three jurisdictions for the same customer, we keep that consent record per-country so a later inquiry from any single regulator can be answered with the exact paperwork it expects. Privacy posture is data minimization on our side and pass-through to the customer's side — we don't retain bulk personal data and we keep credential material off third-party infrastructure.

How we'd reach the data

1. User-consented credentialed integration (recommended)

The customer authorizes the integration against their own Scotia Caribbean credentials. We handle ScotiaCard sign-in, the password step, and the MFA challenge inside a session container the customer controls, then drive the same screens a person would: account list, statement export, recipients list, alerts. Reaches everything the human-facing app can see. Durable across cosmetic UI changes, sensitive to genuine flow changes. Access and any sponsor arrangements are set up with the customer during onboarding — that is part of the build, not a precondition.

2. Documented protocol analysis

Where the customer wants a fully programmatic surface rather than session-driven scraping, we do a documented analysis of the mobile traffic under their authorization: capturing the auth handshake, the session tokens, the JSON shapes the screens consume, and the error states. The deliverable is an OpenAPI-style spec the customer can run themselves, plus the matching client. Slower to first commit, easier to maintain at scale, particularly when the same integration has to cover several of the seven markets.

3. Native PDF export as the floor

If a customer needs only statement-level data, the app's own download-and-share feature is a real fallback — deposit statements over a roughly 13-month window, card statements over roughly 6 months, annual loan statements — pulled through the same authenticated session and parsed on our side. Lower fidelity than route 1 (no intra-day balances, no recipients list), but the simplest thing that ships.

In practice the credentialed session covers most of what a Caribbean integrator actually needs, with the PDF export added on whenever the historical horizon matters. Documented protocol analysis is the right call when the customer plans to host and operate the resulting client themselves rather than consume it as a managed feed from us.

What lands in your repo at the end

• OpenAPI / auth-flow specification. The captured shapes for account list, transactions, statements, recipients, bill payees, alerts, and card controls — modelled per country where the shape differs.
• Runnable source. Python (httpx / asyncio) and Node.js (fetch / TypeScript) clients for the chosen route, with the ScotiaCard / password / biometric-equivalent / MFA handshake wired up and tested against a consenting account.
• Statement parser. A typed parser for the deposit, card, and loan PDF statements, normalized into one schema so an account in Jamaica and an account in Barbados land in the same table.
• Test suite. Replayable fixtures for the auth flow, the statement parser, and the per-country edge cases, runnable in CI without live credentials.
• Interface documentation. A short engineer-facing handover describing the auth chain, the session refresh cadence, the per-country quirks we found, and the operational alarms worth wiring.
• Compliance pack. A consent-record template, a data-retention note for each of the seven jurisdictions, and an NDA where the customer asks for one.

A sketch of the request flow

Illustrative — actual field names and headers are confirmed during the build against a consenting account. The shape captures how a typical fetch sequence looks against the mobile session.

# Pseudocode — Scotia Caribbean session + statement pull
# Authorized integration, customer-consented credentials.

from httpx import AsyncClient

async def open_session(scotiacard, password, country, mfa_callback):
    async with AsyncClient(base_url=f"https://{country}.scotia-mobile.internal",
                           headers={"User-Agent": "ScotiaCaribbean/illustrative"}) as c:
        # Step 1 — initial credential post
        r = await c.post("/auth/login", json={
            "scotiacard": scotiacard,
            "password": password,
            "country": country,             # one of: jm, tt, bb, bs, do, tc, ky
        })
        challenge = r.json()  # {"challenge_id": ..., "channel": "sms"|"email"|"app"}
        # Step 2 — MFA, handled by the customer
        otp = await mfa_callback(challenge)
        r = await c.post("/auth/mfa", json={
            "challenge_id": challenge["challenge_id"],
            "otp": otp,
        })
        session_token = r.headers["x-session"]
        return c, session_token

async def list_statements(c, session_token, account_id, kind):
    # kind in {"deposit","card","loan"} — retention differs per kind
    r = await c.get(f"/accounts/{account_id}/statements",
                    params={"kind": kind},
                    headers={"x-session": session_token})
    # Returns: [{"period":"2026-04", "url":"...", "format":"pdf"}, ...]
    return r.json()

async def download_pdf(c, session_token, statement_url):
    r = await c.get(statement_url, headers={"x-session": session_token})
    # Parse with the shipped statement parser; rows normalize across countries.
    return r.content

Notes from looking at this specific app

• Seven backends, one client. The same app talks to seven country-specific cores. Account-number formats, statement layouts, recipient-bank lists, and alert channels all vary. We map per-country plan rules during the build so a customer holding accounts in both Jamaica and Barbados is aggregated correctly instead of falling through whichever ruleset got coded first.
• Statement windows are bounded. Deposit retention is around 13 months, card is around 6, loan is annual. The integration is designed as a sync rather than a one-shot pull: the first run backfills the available window, then a scheduled job pulls each new statement as soon as it appears and writes it to the customer's archive — nothing is allowed to fall off the rolling edge.
• MFA shape matters. The credentialed flow rests on ScotiaCard plus password plus a one-time challenge, with biometric available for repeat sign-in on the trusted device. We script the integration around an explicit MFA callback the customer controls, so the second factor stays with the human, not with us.
• Frontend churn. The mobile client ships visible updates often — recent ones include dark mode, loan-statement download, and mobile top-up surface changes. We schedule a re-check whenever a release lands, so the parser and the captured request shapes are revalidated against the new build rather than discovered broken by a customer.

How this brief was put together

We worked from the app's own published documentation (the Play Store listing, the Scotiabank country sites for Jamaica, Trinidad and Tobago, the Bahamas and Barbados, and the dedicated help pages on statement viewing), plus the Bank of Jamaica's published FinTech Regulatory Sandbox guidelines for the regional regulatory shape. Specific surface counts (13-month deposit window, 6-month card window, annual loan statement) are taken from the Scotiabank help pages; treat them as confirmed during the build before any customer-facing claim. Sources reviewed:

• Scotiabank Jamaica — Scotia Caribbean app page
• Scotiabank Trinidad & Tobago — viewing e-statements from the app
• Bank of Jamaica — FinTech Regulatory Sandbox Guidelines (Oct 2024)
• Google Play — Scotia Caribbean listing

Reviewed 2026-05-30 by the OpenBanking Studio integration desk.

Other Caribbean mobile banking we've mapped around

Useful when a customer wants a single integration that spans more than one bank in the same market. None of these are interchangeable with Scotia Caribbean; each holds its own subset of the same customer's life. Listed plainly, not ranked.

• NCB Mobile — National Commercial Bank Jamaica. Per-account balances, transactions, third-party transfers, loan and investment views.
• JN LIVE — JN Bank Jamaica. Member-facing balances, transfers, bill payments, and savings club views.
• RBC Caribbean — Royal Bank of Canada's Caribbean app. Balances, transfers, bill pay, cheque deposit, with biometric and soft-token MFA.
• CIBC Caribbean Mobile — CIBC's regional app. Balances, transfers, bill pay, card controls across CIBC's Caribbean footprint.
• First Citizens Mobile — First Citizens, Trinidad and Tobago. Balances, transfers, FX, bill pay.
• Republic Mobile App — Republic Bank, Trinidad-based but with a multi-country Caribbean footprint. Account view, transfers, bill pay.
• Sagicor Bank Jamaica — Balances, transfers, bill pay, with a tighter overlap into insurance and wealth products.
• Bank of the Bahamas Mobile — Account view, transfers, bill pay in the Bahamian market specifically.

Questions integrators ask about this app

Which of the seven Caribbean countries can the integration cover at once?

All seven, in principle — Jamaica, Trinidad and Tobago, Barbados, the Bahamas, the Dominican Republic, Turks and Caicos, and the Cayman Islands all sit behind the same Scotia Caribbean entry point. In practice we scope each build to the markets the customer actually holds accounts in, because country-specific quirks (statement layouts, account-number formats, alert channels) are easier to test against a known list than to claim blanket coverage for.

How is statement retention handled past the 13-month deposit / 6-month card window?

The app exposes a 13-month rolling window for deposit statements and 6 months for credit cards, and only annual PDFs for loans. We design the integration so the first sync runs a full backfill across the available window, then a scheduled job pulls each new statement as soon as it lands and archives it to your side — that way nothing falls off the rolling edge.

Can the build push the data into our existing core banking or CRM stack?

Yes. The deliverable is a typed integration layer, so the same job that pulls Scotia Caribbean records can write them into Postgres, Snowflake, a Salesforce/HubSpot object, or a core-banking adapter. We confirm the target schema during onboarding and ship the mapping as part of the source-code drop.

What does the consent record look like for a Caribbean financial regulator?

Each of the seven countries supervises its own banks (Bank of Jamaica, Central Bank of Trinidad and Tobago, Central Bank of Barbados, Central Bank of The Bahamas, Cayman Islands Monetary Authority, and the Banco Central de la República Dominicana). There is no single Caribbean open-banking instrument to point at, so we work to a written, dated, customer-signed authorization scoped to the specific accounts and data fields, retained alongside the integration logs.

Engagement & contact

We deliver runnable Python or Node source for the Scotia Caribbean integration in one to two weeks, scoped to the country list the customer actually holds accounts in. Source-code delivery starts at $300 and is payable after delivery, once you've reviewed what we shipped and confirmed it runs against a consenting account. The alternative is a pay-per-call hosted endpoint with no upfront fee — you call our API, we bill per call. Give us the country list and what you need from the data, and we will scope the build: start an engagement.