Open banking API platform¶


ID	`MOD-061`
System	SD04
Repo	`bank-payments`
Build status	Not started
Deployed	No

Purpose¶

The open banking API platform is the Data Holder side of the platform's open banking capability. It exposes customer-consented account and transaction data to accredited third-party providers (TPPs) through a standards-compliant API layer, and manages the developer portal and TPP onboarding. Unlike a CDR-only implementation, the platform uses a jurisdiction profile model: the same gateway code serves every supported open banking regime. Enabling a new jurisdiction's open banking is a profile configuration, not a code change or new module deployment.

What it does¶

Jurisdiction profiles¶

The gateway ships with five profiles, each encapsulating the full specification of one open banking regime:

au_cdr — Consumer Data Standards v1.x (AU CDR)
nz_payments_nz — Payments NZ API Centre v2.x
uk_open_banking — OBIE/FAPI 1.0 Advanced
eu_psd2 — Berlin Group NextGenPSD2 v1.3
generic_fapi2 — FAPI 2.0 baseline for any jurisdiction not covered by the profiles above

Each profile defines:

Security profile and token binding requirements — the OAuth 2.0 / FAPI variant, PAR requirements, DPoP or MTLS binding
Consent schema — the fields required in a consent object for that jurisdiction, including mandatory and optional attributes
Scope and permission mapping — translation from the jurisdiction's permission model (e.g., CDR data clusters, OBIE permissions, Berlin Group consent categories) to internal data cluster identifiers
API endpoint structure and versioning convention — resource paths, versioning headers, and pagination format
Accreditation registry source — where TPP credentials are verified: AU CDR Register, NZ directory, UK Open Banking Directory, or equivalent
Rate limits and pagination conventions — per-jurisdiction defaults that can be overridden per TPP

Profile activation is controlled by the openbanking.profiles.enabled configuration list — for example, [au_cdr, nz_payments_nz]. Profiles not in the list are not exposed. Multiple profiles can be active simultaneously on the same gateway instance.

Profile isolation is strict: each active profile has its own base path (/cdr/v1/, /nz/v2/, /uk/v3/, etc.), its own accreditation check against the relevant registry, and its own consent scope validation. A token issued under one profile cannot be used against another profile's endpoints.

Adding a future jurisdiction is a platform update — a YAML profile definition plus an endpoint adapter. No schema migration, no new module, no code fork.

Data Holder API layer¶

The gateway exposes standardised resource endpoints across all active profiles: accounts list, account detail, transactions, balances, direct debits, payees, and customer profile. All responses are normalised to the platform's internal data model before profile-specific serialisation — the same account record renders as CDR JSON, Berlin Group JSON, or UK OBIE JSON depending on the active profile, but the upstream data source is identical.

Pagination, filtering, and date-range parameters are handled consistently across profiles and translated to the profile-specific wire format. Response schemas are validated before dispatch — malformed responses are rejected at the gateway and never returned to the TPP.

FAPI 2.0 — Demonstrating Proof of Possession (DPoP), Pushed Authorisation Requests (PAR), and Rich Authorization Requests (RAR) — is the common security baseline across all profiles. Profiles that require a stricter subset (e.g., MTLS in addition to DPoP) layer that requirement on top of the baseline.

JWT validation is delegated to MOD-044 (RBAC). All inbound tokens carry an ob_profile claim identifying the issuing profile, preventing cross-profile token reuse.

Every resource request is checked against the MOD-049 consent store before data is returned. The specific data clusters or permission codes requested must be present in an active, non-expired consent record for that TPP and customer combination. Revoked consents take effect within 60 seconds — cached consent checks have a maximum TTL of 60 seconds.

Developer portal and TPP onboarding¶

Each active profile has a self-service developer portal for TPP sandbox access, credential management, and API documentation. Documentation is generated from the profile's OpenAPI specification and is always in sync with the deployed endpoint version.

Production onboarding requires accreditation verification against the relevant jurisdiction registry before production credentials are issued. The onboarding flow is profile-specific: AU CDR uses the CDR Register software product record; NZ uses the Payments NZ directory; UK uses the Open Banking Directory. The generic_fapi2 profile requires manual accreditation review.

Audit and monitoring¶

Every API call is logged with: TPP identity, customer identity, profile, endpoint, data clusters returned, consent ID, response time, and HTTP status. Rate limit enforcement applies per TPP and per profile. Alerts fire on accreditation expiry, unusual data volume relative to consent scope, and consent anomalies (e.g., requests against a consent that was revoked within the TTL window).

Compliance reason¶

Open banking is a regulatory obligation in AU (CDR), a Payments NZ initiative in NZ, a mandate in UK (CMA9), and a mandate in EU (PSD2). The profile model means the platform satisfies all of these obligations from a single codebase. A deploying institution expanding from NZ to AU, or from AU to UK, activates the relevant profile without a platform rebuild. The FAPI 2.0 baseline security profile meets or exceeds the security requirements of every supported jurisdiction's standard, so the platform does not need per-jurisdiction security architecture decisions.

Commercial reason¶

TPP ecosystem access is a competitive differentiator — banks offering open banking APIs attract fintech partnerships and account migration flows. The profile model means the vendor's engineering investment in the gateway compounds across jurisdictions: a UK bank deploying this platform gets the same tested, hardened gateway as an AU bank. Time-to-market for open banking compliance in a new country drops from a multi-month build to a profile configuration and accreditation registration.

Module dependencies¶

Depends on¶

Module	Title	Required?	Contract	Reason
MOD-049	Open banking consent management	Required	—	Consent scope validation at the API gateway requires active consent records managed by the consent capture module.
MOD-044	JWT role-based access control	Required	—	JWT validation and scope enforcement for third-party CDR requests relies on the RBAC module.
MOD-075	Internal API gateway	Required	—	CDR API traffic is routed through the internal API gateway for authentication and rate limiting.
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`	Enforces customer consent scope at the API layer — all third-party data requests blocked without valid, active consent.

Capabilities satisfied¶

Capability	Title	Mode	How
CAP-060	CDR Data Holder compliance & consent management	`GATE`	Enforces consent scope at the API gateway — all third-party data requests are blocked without a valid, in-scope consent record.
CAP-061	Commercial API programme & developer portal	`AUTO`	Exposes the commercial API endpoints and developer portal through which third parties access bank data under the CDR framework.
CAP-049	Salary redirect wizard	`AUTO`	Detects the customer's employer from incoming payroll credits and pre-populates the salary redirect wizard with the employer name and the new account BSB and number — the customer sends the pre-filled letter to their employer directly from the app.

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