Confirmation of payee — account name verification¶


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

Purpose¶

Implement Confirmation of Payee (CoP) for non-PayID outbound BSB/account number payments in Australia, satisfying the AU Scam-Safe Accord commitment to verify payee account names before any outbound payment is confirmed. MOD-120 already implements CoP for PayID-identified Osko payments. This module extends name verification to the majority of domestic payment volume — payments routed by BSB and account number without a PayID handle — closing the compliance gap left by MOD-120's scope.

What it does¶

NPP CoP service integration¶

The module integrates with the NPP Confirmation of Payee service, which operates over ISO 20022 messaging through the NPP infrastructure. For each qualifying outbound payment, the module submits the destination BSB, destination account number, and the payee name entered by the customer. The service returns one of four results:

match — the name provided matches the registered account name.
close_match — the name is similar but not identical; the registered name is returned.
no_match — no name similarity; the registered name may or may not be returned depending on the receiving institution's disclosure policy.
unavailable — the CoP service could not be reached or the receiving institution does not participate.

Presentation logic¶

Result handling in the payment confirmation flow:

match — a green match indicator is displayed. The customer may proceed normally without any additional acknowledgement step.
close_match — an amber warning is displayed alongside the actual registered name returned by the service. The customer must actively confirm they wish to continue before the payment instruction is accepted.
no_match — a red warning is displayed, including the registered name where the service has returned one. The customer must actively override, selecting a stated reason from a provided list (e.g. "Business trading name", "Nickname", "I have confirmed the name with the payee directly"). Free-text elaboration is optional but the reason code is required.
unavailable — an amber advisory message is displayed noting that name verification could not be completed. The customer may proceed; no override reason is required. The unavailable result is recorded against the payment.

Override capture and liability record¶

When a customer proceeds past a close_match or no_match result, the override reason is captured and stored. This record constitutes the Scam-Safe Accord liability documentation. Where the customer later claims they were deceived into making the payment, the existence and content of the override record is material to the reimbursement determination under the Accord's consumer reimbursement framework.

CoP checks table¶

All checks are recorded in payments.cop_checks:

Column	Description
`check_id`	UUID primary key
`payment_id`	Foreign key to the payment instruction
`destination_bsb`	BSB submitted to the CoP service
`destination_account`	Account number submitted
`name_provided`	Payee name as entered by the customer
`result`	`match` / `close_match` / `no_match` / `unavailable`
`registered_name`	Name returned by service (null if not returned)
`override_reason`	Reason code selected by customer (null unless overridden)
`acknowledged_at`	Timestamp of customer confirmation or override
`checked_at`	Timestamp of CoP service call

Payment gate enforcement¶

The CoP check is enforced as a gate in the MOD-024 payment initiation flow. A payment instruction cannot be passed to the settlement layer without a cop_check_id reference. The gate is implemented at the payment service level, not in the UI layer, so it cannot be bypassed through alternative API entry points.

Scope and feature flag¶

CoP applies to AU-jurisdiction outbound BSB/account number payments only. The feature flag payments.cop.enabled controls activation at deployment time. NZ A2A payments use a different interbank infrastructure and are not subject to NPP CoP; this module has no effect on NZ payment flows.

Result caching¶

CoP results are cached for 60 seconds keyed on BSB and account number combination. If the customer amends the payment amount or reference and re-triggers the confirmation flow within the cache window, the cached result is used without re-querying the service. Cache entries are invalidated after 60 seconds. Name changes always trigger a fresh service call regardless of cache state.

Batch payments¶

For batch payment files processed by MOD-135, CoP is applied per item at file parse time before the batch is submitted to settlement. Items that return no_match are quarantined and surfaced for operator review in a dedicated exception queue. The operator may approve individual items (with reason recorded) or reject them. Items returning match, close_match, or unavailable pass through automatically, with close_match flagged in the batch report. The batch is not held waiting for the operator to review no_match items — qualifying items are submitted while quarantined items pend separately.

Scheduled and future-dated payments¶

MOD-025 scheduled and future-dated payments trigger a CoP check at initiation time. There is no re-check at execution time. If the customer's payee details change between initiation and execution, the original check result remains on record. This is consistent with industry practice under the Accord.

Compliance reason¶

The AU Scam-Safe Accord, signed by all participating ADIs including COBA credit union members, commits signatories to implement CoP across all outbound payment types. MOD-120 satisfies this obligation for PayID-identified payments. Outbound BSB/account number payments — representing the majority of domestic payment volume by count and value — are not covered by MOD-120. Without this module, the deploying institution's CoP implementation has a material gap and the institution is non-compliant with the Accord. The Accord sets compliance timelines enforced by ABA and reviewed by ASIC and the ACCC; non-compliance carries reputational and regulatory risk.

Commercial reason¶

CoP directly reduces authorised push payment (APP) fraud losses. Under the Accord's consumer reimbursement framework, a financial institution that has implemented CoP and documented a customer's informed override of a no_match result has a stronger position when assessing reimbursement liability than one that performed no name check at all. Reduced fraud losses flow through to lower provisioning requirements and lower operational cost from fraud investigation and recovery work. CoP also reduces false-routing errors — payments sent to a legitimate but unintended account due to a transcription mistake in the BSB or account number — which generate material operational cost in reversal requests, recalls through NPP, and customer remediation.

Module dependencies¶

Depends on¶

Module	Title	Required?	Contract	Reason
MOD-024	Device & session intelligence	Required	—	Domestic outbound payment initiation calls the CoP service before presenting the confirmation screen — the payment cannot proceed without a CoP result.
MOD-025	FX rate lock & conversion	Required	—	Scheduled and future-dated payments are subject to CoP check at initiation time.
MOD-120	PayID and Osko integration	Optional	—	PayID/Osko payments use PayID resolution for CoP; this module handles non-PayID BSB/account payments through the NPP CoP service.
MOD-048	System decision log	Required	—	CoP result, customer acknowledgement, and any override with reason are recorded as decision log entries.
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.
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.

Required by¶

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

Policies satisfied¶

Policy	Title	Mode	How
PAY-005	Payment Fraud Prevention Policy	`GATE`	Payee name is verified against the destination account before the customer can confirm any outbound payment — name mismatch or no-match result is shown and must be acknowledged before proceeding.
PAY-003	Card Scheme Compliance Policy	`AUTO`	CoP result and customer acknowledgement are recorded with the payment record for fraud liability and audit purposes.

Capabilities satisfied¶

(No capabilities mapped)

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