Skip to content

Payment Routing, Sponsor & Card-Scheme Abstraction Policy
Code PAY-008
Domain Payments & Settlement
Owner Head of Payments
Status Draft
Applicability Platform
Jurisdiction NZ + AU
Business domain BD06
Review date 2027-04-01

Regulations: AU Payment Systems Act · Payments NZ Rules · Visa/Mastercard Rules

Purpose

Govern the payment routing layer and the abstraction model for sponsor bank relationships. Defines how the platform selects the optimal rail and sponsor for each payment type, controls routing configuration changes, and manages the risk and operational dependency on sponsor bank infrastructure.

Scope

All payment instructions routed through sponsor bank or scheme connections, including NPP, BECS, RTGS, and NZ payment clearing arrangements. Applies to both NZ and AU jurisdictions where a sponsor or settlement agent relationship is required.

Policy statements

The platform SHALL maintain a centralised routing configuration that maps each payment type, currency, and threshold combination to the preferred and fallback rail or sponsor. Routing configuration SHALL be version-controlled and SHALL require documented approval before any change is applied to production.

The payment orchestration engine SHALL select the correct rail and sponsor for each instruction based on the current routing configuration. No instruction SHALL be routed by ad hoc or hardcoded logic outside the routing engine.

Where a primary sponsor or rail is unavailable, the routing engine SHALL apply the documented fallback path. Fallback activation SHALL be logged and SHALL trigger an operational alert. Continued use of a fallback path beyond the defined threshold SHALL escalate to the Head of Payments.

The platform SHALL monitor real-time settlement position per sponsor. Where a sponsor position approaches the defined exposure limit, the routing engine SHALL alert the treasury function and, if the limit is reached, queue rather than route additional instructions until the position is reduced or an exception is approved.

All sponsor bank relationships SHALL be governed by documented service agreements covering settlement cut-off times, fail-safe procedures, fee schedules, and notification obligations. The Head of Payments is responsible for maintaining current agreements.

Changes to sponsor routing configuration SHALL be tested in the staging environment before production deployment. Change records SHALL document the test outcomes.

All routing decisions, fallback activations, and sponsor position alerts SHALL be logged in the immutable transaction log.

Card scheme abstraction

This section extends the sponsor abstraction model to card scheme connectivity, per ADR-058 (credit card platform boundary).

The platform SHALL maintain a card-scheme abstraction layer that hides the identity of the underlying issuer-processor and card scheme from all product, ledger, and credit modules. Product and ledger code SHALL NOT contain Visa-specific or Mastercard-specific logic outside the abstraction layer.

Scheme neutrality. Visa-vs-Mastercard SHALL be a configuration choice per BIN range, not a hard-coded path in product or ledger code. A single product (e.g. a credit card) may be offered on either scheme by changing the BIN range configuration; no code change SHALL be required.

Processor neutrality. The internal interface to the issuer-processor SHALL be a single, stable API contract. Switching from one processor to another (e.g. Marqeta to Paymentology) SHALL not require changes to product, credit, or ledger modules — only to the implementation of the abstraction layer in bank-payments.

JIT-funding webhook. The platform SHALL expose a Just-in-Time funding webhook endpoint to the processor for credit card authorisations. This endpoint is the only platform component that sits in the sub-100ms card-auth path. It SHALL be architecturally isolated from any blocking I/O; it SHALL not call external services synchronously during the response. Performance target: p99 response time < 80ms under steady-state load (MOD-167 responsibility).

Tokenisation event normalisation. Token lifecycle events from Visa Token Service and Mastercard Digital Enablement Service (MDES) SHALL be normalised to a single internal event shape before any platform module processes them. Modules SHALL not receive raw VTS or MDES webhook payloads.

Processor-switch covenant. Any issuer-processor agreement SHALL require, as non-negotiable commercial terms: (a) full data export capability for all card and transaction records; (b) PAN/token portability — the ability to migrate the token vault to a replacement processor without customer re-enrolment in Apple Pay or Google Pay; (c) documented schema and API versioning with a minimum 12-month deprecation notice.

BIN range sponsorship. Credit-card BIN ranges require a sponsor bank with credit-card BIN sponsorship capability. This is a distinct relationship from the debit/eftpos sponsorship under ADR-005. The Head of Payments is responsible for maintaining current credit-card BIN sponsorship agreements. The bin_range_type column on payments.physical_cards records whether a given card's BIN is sponsor-held ('sponsor') or platform-held under direct scheme membership ('principal').

Scheme bulletin compliance. The platform SHALL treat scheme rule compliance (Visa/Mastercard bulletins) as an ongoing operational capability, not a one-time implementation task. A designated payments-rules process SHALL ensure scheme bulletins are reviewed, assessed for impact, and actioned before the effective date. The Head of Payments is responsible.

Satisfying modules

Module Name Mode Description
MOD-082 Nostro & FX treasury management AUTO Nostro account positions are reconciled against correspondent bank statements on every settlement cycle — discrepancies are flagged automatically for treasury review.
MOD-167 Credit card facility engine AUTO JIT-funding webhook responds to issuer-processor authorisation requests within p99 < 80ms by querying available credit in-process with no blocking external I/O.

Part of Payments & Settlement · Governance overview Compiled 2026-05-22 from source/entities/policies/PAY-008.yaml