ADR-058: Credit card platform boundary — in-platform vs external capability assignment¶
| Status | Accepted |
| Date | 2026-05-08 |
| Deciders | CEO, CTO, Head of Payments, Head of Credit |
| Affects repos | bank-payments, bank-credit, bank-app, bank-core |
Status¶
Accepted — 2026-05-08
Context¶
A credit card programme will eventually be added to the product set. This ADR records the architectural boundary between what the platform builds and owns versus what is sourced from card schemes, issuer-processors, or sponsor banks. It extends ADR-005 (payments partner at launch) to cover card scheme membership and credit-card BIN sponsorship explicitly, and is the load-bearing reference document for any future credit card programme.
Three external context shifts justify fixing this boundary now, before a credit card product is greenlit.
Issuer-processor market maturity. The modern API-first issuer-processor tier (Marqeta, Paymentology, Thredd, Highnote, Galileo, Lithic) has compressed what was a 12-month scheme-integration project into a 6–12-week onboarding. Paymentology launched in Australia in April 2026 with local infrastructure and a Cuscal partnership; Marqeta has had AU presence for several years. The case for building scheme connectivity in-house has collapsed against this backdrop for a bank of this scale.
Flexible-credential convergence. Visa Flexible Credential (live since late 2024) and Mastercard One Credential (launched February 2025) let a single tokenised PAN route between debit, credit, instalments, and rewards under issuer-set rules. This reinforces rather than blurs the boundary: the bank still owns the credit decision, the limit, and the balance — only the routing rule lives at the scheme and is expressed via MOD-051 (financial automation rules engine) once both debit and credit accounts are live.
Interchange cap convergence. NZ domestic credit-card interchange is capped at 0.30% in-person from 1 December 2025 (Commerce Commission Final Decision, 17 July 2025). The RBA has confirmed a matching 0.30% AU cap from 1 October 2026. Credit card revenue for a new entrant will come primarily from revolving interest income, annual fees, and data — not interchange. This makes the boundary even clearer: the parts of the stack that generate revenue (balance, interest accrual, limit management) are platform; the parts that generate interchange (scheme connectivity, authorisation switch) are external.
Decision¶
A credit card programme is treated as two distinct concerns joined by a thin interface: a payment device (always external) and a credit product (always platform).
Three-tier capability assignment¶
Tier 1 — Always external. These capabilities touch the card scheme network or a PCI-scoped cardholder data environment in ways that make in-house provision economically irrational or regulatorily disproportionate for a bank of this scale.
| Capability | Where it lives | Notes |
|---|---|---|
| Card BIN allocation & scheme membership | Scheme + sponsor bank | Per ADR-005 sponsor model extended to cover credit-card BIN ranges |
| PAN generation & PCI vault | Issuer-processor | Keeps the platform out of PCI DSS Level 1 scope per PAY-006. Full PANs never enter Neon. MOD-124 stores pan_last4 only |
| Card scheme connectivity (ISO 8583 / DPS Forward / Mastercard Processing Core) | Issuer-processor | Processor handles the on-the-wire scheme connection |
| Authorisation switch & online auth response | Issuer-processor | Sub-100ms response window required by schemes. The platform responds to the processor's JIT-funding webhook — it does not sit in the auth path end-to-end |
| Tokenisation & wallet provisioning (Apple Pay, Google Pay, click-to-pay) | Visa Token Service / MDES via processor | Already factored into MOD-124 for debit cards. Same path for credit |
| 3D Secure / EMV 3DS step-up | Scheme / processor | Risk data signal can be enriched by MOD-024 (device & session intelligence) but the protocol is at the scheme |
| Scheme dispute rails (VROL, Mastercom Claims Manager) | Scheme via processor | Mandatory scheme rails. Accessed through the processor's PCI-isolated wrapper, not directly from the platform |
Tier 2 — Hybrid. These capabilities have value layered on top of what the scheme or processor provides. The platform consumes a primary signal from the external layer and overlays internal context.
| Capability | Where it lives | Notes |
|---|---|---|
| Real-time transaction fraud scoring | Scheme/processor primary + MOD-023 | Visa Risk Manager / Mastercard Decision Intelligence give a cross-issuer base score. MOD-023 layers customer history and SD06 model signals |
| Per-card controls (freeze, category block, daily limits, virtual card) | MOD-078 + processor | MOD-078 owns the customer UX. MOD-021 enforces on platform-initiated payment instructions. Processor holds a current copy of limit and freeze state for card-present auth, synchronised in near real-time by MOD-078 |
| Dispute case workflow | MOD-053 + processor | MOD-053 holds the customer-facing dispute case. Processor holds the chargeback claim record. Linked by an external case reference |
| Merchant data enrichment & categorisation | MOD-041 + scheme | Schemes supply MCC and merchant name; MOD-041 cleans, deduplicates, and personalises. Same as for debit |
Tier 3 — Always platform. Anything that touches the bank ledger, the credit decision, customer disclosure, regulatory reporting, or the customer relationship.
| Capability | Where it lives | Notes |
|---|---|---|
| Credit limit assignment & affordability | MOD-027, MOD-028, MOD-029 | CCCFA / NCCP responsible lending obligations are non-delegable. No change to existing modules |
| Revolving balance, billing cycle, interest accrual, minimum repayment, statement | Future MOD-167 (credit card facility engine) | Substantive new SD05 module. Pattern follows MOD-117 (overdraft management). The only new platform build required for a credit card programme |
| ECL provisioning | MOD-031 | Extends trivially to credit card asset class |
| RWA calculation | MOD-033 | Credit card exposures feed in via MOD-001 postings |
| IRRBB modelling | MOD-035 | Variable-rate revolving credit exposure |
| Statements, fee disclosure | MOD-113, MOD-110 | Extend to credit card asset class and comparison-rate calculation |
| Hardship treatment | MOD-139 | CON-008 hardship obligations apply identically |
| AML/CTF transaction monitoring | MOD-016, MOD-017 | No architectural change; credit card transactions flow via MOD-001 → CDC |
| Credit reporting | MOD-128 | Add credit card account type to CCR schema |
| Product disclosure & DDO/TMD | MOD-155 | Add credit card Target Market Determination |
| Customer relationship (in-app UI, notifications, history) | SD08 | Customer never interfaces with an issuer-processor screen |
The JIT-funding interface¶
The one performance constraint the platform owns in this boundary is the Just-in-Time funding webhook — the processor calls the bank during an authorisation to check available credit before approving. The platform must respond within the scheme-required sub-100ms window. MOD-167 (credit card facility engine) is responsible for this endpoint and must be designed for p99 < 80ms under steady-state load. This is the tightest latency SLA anywhere in the platform and must be architecturally isolated from any blocking I/O path.
Structural changes flowing from this decision¶
-
ADR-005 extended. The payments-partner-first principle now covers card scheme membership and credit-card BIN sponsorship explicitly. The same abstraction model applies: scheme-neutral, processor-neutral internal interface (PAY-008).
-
MOD-124 extended. The
card_typeCHECK constraint is widened to include'credit'. Acredit_facility_idcolumn (optional UUID, no DB-level FK) links a credit card record to the future MOD-167 credit facility. Abin_range_typecolumn ('sponsor'|'principal') records whether the BIN is held via a sponsor or, in a future state, via direct scheme membership. These changes are made before MOD-124 is built to avoid a schema migration. -
PAY-008 extended. The sponsor abstraction policy is extended to include a card-scheme abstraction layer: Visa-vs-Mastercard is a configuration choice per BIN range; processor-vs-scheme-direct is a single internal interface; tokenisation events from VTS and MDES land on a normalised internal shape. See PAY-008 for the full policy statement.
-
MOD-167 created when greenlit. The credit card facility engine is the only substantive new module. Until a credit card product is formally greenlit it is not built. The data model preparation in MOD-124 and the abstraction preparation in PAY-008 are the complete pre-work.
Consequences¶
Positive - The platform never enters PCI DSS Level 1 cardholder data environment scope — PANs stay in the processor's vault, consistent with PAY-006 and existing MOD-124 design - No card scheme certification investment at this scale — fully consistent with ADR-005 - The processor can be switched or a second processor added (dual-scheme) without touching product or ledger code, because the abstraction layer (PAY-008) hides the processor identity - Credit economics under the 2025–2026 interchange caps (revolving interest, annual fees) are served by the platform's strongest capabilities; interchange-dependent capabilities stay external - Phase 1 work (MOD-124 data model extension, PAY-008 amendment) is near-zero cost because both modules are pre-build
Negative / trade-offs - The JIT-funding webhook is a latency-critical interface the platform owns. Any performance regression in MOD-167's credit-check path directly affects card authorisation rates - The processor holds the customer's tokenised PAN lifecycle. PAN portability (switching processor while preserving customer tokens) must be a procurement non-negotiable - Revolving interest income and balance management are the platform's revenue levers — MOD-167 is IP, not commodity. It requires careful product engineering - NZ data residency: for any global issuer-processor, the cardholder data environment (PCI vault) will sit in AU rather than NZ. DT-008 (third-party & outsourcing risk) must explicitly address this against BS11 and the NZ DTA Outsourcing Standard before a NZ credit card programme launches
Constraints this creates for bank-payments and bank-credit¶
- No PAN storage anywhere in Neon — card_type='credit' in
payments.physical_cardsstorespan_last4only, identical to debit - All processor interactions go through the PAY-008 abstraction layer — no processor-specific code in product or ledger modules
- The JIT-funding webhook in MOD-167 must respond p99 < 80ms; it must not block on external I/O during the response path
- Scheme-specific dispute rail access (VROL, Mastercom) only via the processor's PCI-compliant wrapper — never direct from the platform
Principles alignment¶
| Principle | Assessment | Notes |
|---|---|---|
| AP-001 KISS | ✓ | Don't build scheme connectivity; let the processor absorb that complexity |
| AP-006 Cost effective | ✓ | Processor amortises PCI and certification cost across hundreds of clients; per-transaction pricing scales with volume |
| AP-007 Evolution by design | ✓ | PAY-008 abstraction preserves option to switch processor, add a second scheme, or move to direct membership |
| AP-009 Robust and serviceable | ~ | Processor is a third-party dependency; SLA monitoring required per NFR-020 |
Perspectives¶
| Perspective | Assessment | Notes |
|---|---|---|
| Performance & Scalability | ~ | JIT-funding webhook is the critical latency path; MOD-167 must be designed for p99 < 80ms |
| Strategy | ✓ | Standard modern-bank approach; consistent with how Revolut, Up, and other neobanks have launched credit products |
| Resilience & Availability | ~ | Processor failure = card payment failure; same risk profile as the existing sponsor model per ADR-005 |
| Integration | ✓ | PAY-008 abstraction layer is the integration boundary; processor integration is a configuration, not a build |
| Cost | ✓ | Per-active-card and per-transaction processor pricing is appropriate at launch volume |
| Regulatory | ✓ | Platform retains all non-delegable obligations (responsible lending, ECL, RWA, AML, disclosure) |
| Security | ✓ | PANs never enter Neon; PCI scope unchanged from current debit card design |
Phasing¶
Now (pre-product decision): Extend MOD-124 data model (credit card columns). Extend PAY-008 (card-scheme abstraction). Run processor scan (Marqeta, Paymentology, Thredd, Highnote, Cuscal).
Phase 1 (debit launch): MOD-124 built with credit-ready schema. PAY-008 abstraction active.
Phase 2 (credit card greenlit): Build MOD-167 (credit card facility engine). Extend MOD-027/028/029 for credit-card affordability cohort. Add credit card asset class to MOD-031/033/035/110/113/128. Author TMD in MOD-155. Processor integration through PAY-008 abstraction.
Phase 3 (pilot): Single jurisdiction, single product, invitation cohort. VROL/Mastercom through processor wrapper. MOD-053 for customer dispute cases.
Phase 4 (scale): Second product. Dual-scheme option. Visa Flexible Credential / Mastercard One Credential routing via MOD-051.
Related decisions¶
| ADR | Title | Relationship |
|---|---|---|
| ADR-005 | Payments partner at launch — direct scheme membership deferred | This ADR extends ADR-005 to cover card scheme membership and credit-card BIN sponsorship |
| ADR-014 | Launch product set | Credit cards are deferred beyond MVP. This ADR defines the boundary for when they are added |
Signoff record¶
| Date | Name | Role | Status |
|---|---|---|---|
| 2026-05-08 | Ross Millen | CTO | Approved |
| 2026-05-08 | Ross Millen | Head of Payments | Approved |
| 2026-05-08 | Ross Millen | Head of Credit | Approved |
All ADRs
Compiled 2026-05-22 from source/entities/adrs/ADR-058.yaml