Payment Operations Policy¶


Code	`PAY-001`
Domain	Payments & Settlement
Owner	Head of Payments
Status	Draft
Applicability	Platform
Jurisdiction	NZ + AU
Business domain	BD06
Review date	2027-03-25

Regulations: AU Payment Systems Act · Payments NZ Rules · NPP Rules ¶

Purpose¶

Govern payment processing standards across all payment types, channels, and rails operated by the platform. Defines authorisation controls, lifecycle state requirements, settlement window obligations, idempotency controls, and the handling of failed, rejected, or ambiguous payment events.

Scope¶

All payment instructions initiated by or on behalf of customers, including domestic transfers, bill payments, direct debits, direct credits, and inbound credit receipts, across NZ and AU jurisdictions.

Payment lifecycle¶

Every payment instruction SHALL progress through a defined set of states. State transitions SHALL be logged with timestamps, agent identifiers, and the triggering event.

State	Meaning
Received	Instruction accepted at the platform boundary; format validation passed.
Validated	Pre-execution checks complete (balance, limits, account state, sanctions, fraud).
Authorised	Customer or system authorisation confirmed; instruction committed to processing.
Submitted	Instruction submitted to the scheme or sponsor bank.
Accepted	Scheme or sponsor has accepted the instruction for settlement.
Settled	Final settlement confirmed; posting applied to ledger.
Failed	Instruction could not be completed; reason code recorded; funds returned or held.
Returned	Receiving bank or scheme has returned the payment post-submission.
Reversed	A technical correction reversal has been applied through the posting engine.

Policy statements¶

Every payment instruction SHALL pass a sequenced set of pre-execution checks before any financial effect is applied. These checks SHALL include: account state validation, balance and limit checks, sanctions screening, fraud pre-screening, and format validation. No check may be bypassed or deferred to post-execution.

Every payment instruction SHALL carry a unique idempotency key. Where the same instruction is received more than once within the idempotency window, the platform SHALL return the result of the original instruction without reprocessing. Duplicate detection SHALL operate across all channels and ingress paths.

Channel authentication SHALL be verified as part of the pre-execution check sequence. Payments initiated through the customer mobile or web channel SHALL require at minimum a valid authenticated session. High-value or new-payee payments SHALL be subject to step-up authentication as defined in PAY-005.

Payment instructions SHALL be processed in accordance with the applicable rail's settlement window and cut-off times. Payments received after cut-off SHALL be queued for the next settlement cycle unless same-day treatment is explicitly supported.

Where a payment instruction cannot be completed, the platform SHALL apply a deterministic failure disposition: return the funds to the originating account with a reason code, or route to a controlled suspense state with durable traceability. Silent failure is prohibited.

Reversals and recalls SHALL follow the procedures defined in PAY-009. Unilateral reversal of a settled payment is prohibited outside the agreed recall framework.

Payment authorisation limits SHALL be enforced per account type, product, and channel. Limit exceptions SHALL require documented approval and SHALL be time-bounded.

The platform SHALL reconcile payment settlement positions at each settlement cycle. Breaks identified in reconciliation SHALL trigger alerts and SHALL be resolved within the timeframes defined in the reconciliation policy.

All payment instructions, state transitions, and settlement confirmations SHALL be recorded in the immutable transaction log.

Satisfying modules¶

Module	Name	Mode	Description
MOD-001	Double-entry posting engine	`GATE`	Payment posting enforces settlement finality — entry is atomic and irreversible
MOD-003	Real-time balance engine	`GATE`	Sufficient funds check uses real-time balance before authorising any payment
MOD-013	Real-time sanctions screener	`GATE`	Payment processing blocked for sanctioned parties before funds move
MOD-020	Pre-payment validation suite	`GATE`	No payment leaves the bank without passing all pre-flight checks — enforced as sequential gate
MOD-051	Financial automation rules engine	`GATE`	Automated payments subject to same pre-payment validation as manual payments
MOD-071	Payment initiation	`GATE`	Presents the full payment details for customer confirmation before submission — no payment is initiated without explicit customer authorisation.
MOD-110	Fee engine	`AUTO`	Fees are posted as double-entry ledger entries via MOD-001 — fee debit from the customer account, credit to the bank's fee income GL account — in a single atomic transaction.
MOD-111	Term deposit maturity engine	`AUTO`	Maturity proceeds are disbursed automatically on the maturity date per the customer's standing instruction, with no manual intervention required.
MOD-114	Direct debit mandate management	`GATE`	A direct debit is only processed against an account if a valid active mandate exists for the requesting biller — no mandate, no debit.
MOD-116	Mortgage servicing engine	`AUTO`	Scheduled repayments are initiated as automatic payments via the payment engine on their due date.
MOD-117	Overdraft management engine	`GATE`	Outgoing payments that would exceed the combined available balance (credit + overdraft limit) are declined before execution.
MOD-119	BPAY payment integration	`GATE`	BPAY payments are validated against biller code, customer reference number format, and payment amount limits before submission to the BPAY scheme.
MOD-120	PayID and Osko integration	`GATE`	PayID-addressed payments are validated for PayID existence and account reachability before funds are committed.
MOD-122	NZ faster payments and A2A integration	`GATE`	All outbound NZ interbank payments pass pre-payment validation (balance, sanctions, daily limits) before submission to the Payments NZ clearing network.
MOD-123	ATM network integration	`GATE`	ATM withdrawal requests are validated in real time against the customer's available balance and daily ATM limit before authorisation is returned to the network.
MOD-129	Teller operations and branch cash management	`GATE`	All teller-initiated postings pass the same pre-payment validation (available balance, account status, sanctions screen) as digital channel payments — no teller bypass path exists.
MOD-135	Batch payment and payroll file processing	`GATE`	Source account available balance is checked against the total batch amount before any item is processed; if funds are insufficient the batch is held and the customer notified.
MOD-136	BPAY biller registration and inbound BPAY	`AUTO`	Inbound BPAY payments are credited to the biller's account automatically upon receipt from the sponsor bank settlement file; no manual processing step for standard inbound payments.
MOD-137	Agency banking adapter	`GATE`	Each agency transaction in the batch file is validated against account status and available balance before posting; items that fail validation are quarantined with a structured failure reason.
MOD-141	Intra-bank transfer engine	`GATE`	Intra-bank transfers pass pre-payment validation — available balance, account status, and transaction limits — before posting; the transfer is not posted if the source account has insufficient funds.

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