Skip to content

Open banking data access — data recipient
ID MOD-084
System SD04
Repo bank-payments
Build status Not started
Deployed No

Purpose

The open banking data recipient module enables the platform to act as a Data Recipient — obtaining customer-consented access to data held at another institution — across any supported open banking jurisdiction. This allows the platform to retrieve account, transaction, and identity data from a customer's existing bank to support account migration, affordability assessment, and account pre-population. Unlike a CDR-only data recipient, this module uses the same jurisdiction profile model as MOD-061 and MOD-049, connecting to external institutions over whichever open banking standard they expose.

What it does

Supported profiles and connection model

For each active jurisdiction profile, the module connects as an accredited Data Recipient:

  • AU CDR: registered as a Data Recipient on the CDR Register; connects to AU banks via Consumer Data Standards API
  • NZ (Payments NZ): registered with Payments NZ directory; connects to NZ banks via API Centre specification
  • UK Open Banking: registered with the UK Open Banking Directory (OBIE); connects via FAPI 1.0 Advanced / OBIE Read/Write API
  • EU PSD2: registered as an AISP/PISP with relevant NCA; connects via Berlin Group NextGenPSD2 API
  • Generic FAPI 2.0: connects to any institution exposing a FAPI 2.0 compliant API, using dynamic client registration

The connection layer is abstracted: each profile has a connector that handles that jurisdiction's token exchange, endpoint discovery, and response normalisation. The consuming workflow receives a normalised data structure regardless of source profile.

Use cases

Three consuming workflows use the data recipient capability:

  1. Account migration pre-fill: customer consents to retrieve their account list, direct debits, and payee list from their current bank. MOD-062 orchestrates the migration; this module fetches the data.
  2. Affordability assessment: customer consents to share transaction history. MOD-027 (affordability) receives normalised transaction data for income/expense analysis without screen-scraping.
  3. Account opening pre-fill: customer consents to share name, address, and contact details from their current bank to pre-populate the KYC form, reducing friction at onboarding.

Before any outbound request, MOD-049 consent is checked: (external_institution_id, customer_id, requested_scopes) must be valid and active.

Retrieved data is stored in a purpose-scoped temporary store with a TTL tied to the consuming workflow — data is deleted when the workflow completes or is abandoned, whichever is sooner.

Data is never retained beyond the declared purpose. Retention policy is enforced at the data layer, not application logic — TTL expiry triggers hard deletion.

All retrieval events are logged: external institution, profile, scopes requested, data received (volume only, not content), consuming workflow, and deletion timestamp.

Connection directory and discovery

Each profile maintains an institution directory (fetched from the relevant accreditation registry on a daily schedule) listing all Data Holders the platform can connect to, their endpoint discovery documents, and their accreditation status.

Customers see a searchable list of connectable institutions within the consent initiation flow.

Compliance reason

As a Data Recipient, the platform is subject to the data recipient obligations of each active jurisdiction — AU CDR Rules, NZ API Centre terms, OBIE Data Recipient terms, GDPR (EU). Normalising to a single retrieval module means the data handling obligations (purpose limitation, deletion, consent validation) are implemented once and applied consistently across all jurisdictions. A jurisdiction-specific implementation would duplicate these obligations with different code paths, increasing the risk of inconsistent behaviour.

Commercial reason

Data recipient capability is the unlock for frictionless account migration — the strongest customer acquisition tool for a challenger bank. Connecting to a customer's existing bank over open banking and pre-filling their direct debits and payees reduces the migration effort from hours to minutes. Expanding this to affordability pre-fill creates a faster, more accurate credit decision than self-declared income.

Module dependencies

Depends on

Module Title Required? Contract Reason
MOD-049 Open banking consent management Required — Customer consent for CDR data retrieval must be captured and validated before any request to the Data Holder.
MOD-062 Workflow orchestration engine Required — Retrieved CDR data is fed into the account migration workflow orchestrated by the workflow engine.
MOD-027 Affordability calculator Optional — Affordability assessment workflow may consume retrieved open banking transaction data for income and expense analysis when the customer consents to use of their bank transaction history.
MOD-104 AWS shared infrastructure bootstrap Required — AWS shared infrastructure provisioned by MOD-104 (EventBridge buses, S3, KMS, Kinesis, Cognito) is required before this module can be deployed.
MOD-103 Neon database platform bootstrap Required — Neon database and schema provisioned by MOD-103 must exist before this module can read or write Postgres.

Required by

(No modules in this wiki currently declare a dependency on this module.)

Policies satisfied

Policy Title Mode How
PAY-010 Open Banking & API access GATE Customer consent for open banking data retrieval is validated against the MOD-049 consent store before any request is made to the external Data Holder — no retrieval without explicit, in-scope, profile-appropriate consent
PRI-001 Privacy Policy AUTO Retrieved open banking data is used only for the purpose declared at consent and is deleted after the consuming workflow (migration, affordability assessment, or account pre-fill) completes — purpose-binding is enforced per jurisdiction profile requirements

Capabilities satisfied

Capability Title Mode How
CAP-131 Inbound CDR data retrieval for account migration AUTO Acts as a CDR Data Recipient — obtains customer consent, retrieves account and transaction data from the customer's nominated Data Holder bank via the CDR API, and pre-populates the account migration workflow to minimise manual re-entry.

Part of SD04 — Payments Processing Platform Compiled 2026-05-22 from source/entities/modules/MOD-084.yaml