NPP, Osko and PayID explained from the wire up

What NPP actually is and how it was built

The New Payments Platform is a shared, always-on, real-time retail payments infrastructure for Australia. It went live in February 2018 after a five year build coordinated by the Reserve Bank of Australia and the major Australian banks. It is co-owned by the participating financial institutions, operated by NPP Australia Limited (NPPA), and settled through the RBA's Fast Settlement Service.

Architecturally NPP is a hub-and-spoke network. Participants connect to a central switch operated by NPPA over a private network provided by SWIFT. Messages exchanged between participants use the ISO 20022 messaging standard. A central Addressing Service maps human-readable identifiers to underlying account details. Settlement happens in real time on every transaction through the FSS.

NPP replaced the batch-oriented Bulk Electronic Clearing System (BECS, also known as Direct Entry) for most retail transfer use cases. BECS still processes payroll and some scheduled flows; NPP handles most person-to-person, consumer-to-merchant and small business transfers.

Participants include every major Australian bank, most regional banks, the neobanks and a growing number of building societies, mutual banks and credit unions. The RBA publishes the participant list publicly. Not all AU ADIs are direct participants; smaller institutions often connect through a settlement bank partner.

What Osko is and how it sits on top of NPP

Osko is an overlay service on top of NPP, launched by BPAY Group and now operated by Australian Payments Plus following the 2022 consolidation of BPAY, eftpos and NPP into a single industry entity. Osko is what most retail bank apps mean when they refer to instant transfers.

Structurally, an Osko payment is an ISO 20022 pacs.008 credit transfer message with an Osko service level identifier attached. That identifier commits the participants to Osko's service-level agreement (near-instant settlement, defined remittance payload, structured party details).

The distinction between Osko and vanilla NPP matters less to consumers than to implementers. Every PayID payment that a retail bank app initiates is an Osko payment; not every message on NPP uses Osko. Non-Osko NPP messages tend to be corporate or wholesale flows where the participants have negotiated a different service level.

What PayID is and how it maps identifiers to accounts

PayID is the addressing service that sits inside NPP infrastructure and resolves human-readable identifiers to underlying bank account routing details. It is not itself a payment product; it is the address layer that makes the payment easier for humans to originate.

Supported identifier types include email addresses, mobile numbers, Australian Business Numbers (ABNs) and organisation identifiers. Each identifier maps to exactly one bank account across the entire NPP system, enforced centrally by the Addressing Service.

Registration happens at the customer's bank. To register a PayID, a customer proves ownership of the identifier (typically via a click-through on an email or a code sent by SMS), then registers the identifier against their account. The Addressing Service maintains the central registry.

Ownership is unique at any point in time. If a customer switches banks, the PayID identifier can be transferred to the new account through a documented transfer process. Deregistration is a one-tap operation in most bank apps.

The anatomy of an ISO 20022 pacs.008 credit transfer

The specific message that carries a PayID payment across NPP is a pacs.008.001 FIToFICustomerCreditTransfer message. This is a global ISO 20022 standard, adopted across NPP, SEPA Instant, FedNow and SWIFT gpi.

Key elements. GroupHeader carries the message identifier, creation timestamp and settlement information. CreditTransferTransactionInformation carries the payer details, payee details, amount, remittance information and purpose code.

The party details are structured. Payer and payee each have identity, address, account and identification fields. NPP-specific extensions add the PayID identifier as an account alias and carry additional Australian regulatory tags.

The remittance information field is the consumer-visible payload, up to 280 characters, structured or unstructured. This is where operator reference codes travel and where a personal note on a peer transfer lives.

The purpose code is a categorisation used by banks and regulators for anti-money-laundering screening. Codes are drawn from the ISO 20022 external code list; for consumer flows the default is often GDDS or a similar generic value.

The Addressing Service resolution flow in detail

The Addressing Service flow is what happens between the moment a payer types a PayID identifier and the moment the confirmation of payee name is displayed for approval. It runs across three distinct network hops.

Hop one. The payer's bank sends a resolution request to the central Addressing Service, carrying the PayID identifier. The Addressing Service looks up the registered account and returns the beneficiary financial institution identifier and the registered account name.

Hop two. The payer's bank optionally sends a name-verification query to the beneficiary bank via NPP messaging, to confirm the returned name matches the current registered name at the beneficiary side. This second hop protects against stale central registry data.

Hop three. The payer's bank returns the resolved name to the payer's app, which displays it prominently for confirmation. The payer taps to approve, and the bank formats the pacs.008 message.

All three hops complete in well under one second in normal operation. The user-visible latency is typically dominated by the bank app's own rendering rather than by the network hops.

pacs.008 for credits and pacs.004 for returns

pacs.008 is the credit transfer message. It carries value from payer to payee. Its counterpart, pacs.004, is the return message used when a payment cannot be posted at the beneficiary side and must be sent back.

Return scenarios include a closed beneficiary account, a mismatch between the resolved PayID and the underlying account, or a fraud-team hold at the receiving bank. Returns preserve the reference information from the original pacs.008 so the payer's bank can reconcile the returned amount back to the original outbound transaction.

For pokies flows, pacs.004 returns are rare. When they do happen, the typical trigger is an operator's payment gateway rejecting an inbound credit because the reference code did not match any pending player account. This behaviour is unusual and it is worth flagging with the operator's support.

Mistaken payment handling and the AFCA framework

Mistaken payments happen. A payer types the wrong PayID identifier, or approves a payment to a payee whose registered name did not match what was expected. The Australian mistaken-payment framework, elaborated through AFCA case decisions and the ePayments Code, defines the recovery process.

Step one. The payer contacts the sending bank as soon as the mistake is discovered. The sending bank is required to attempt recovery in good faith.

Step two. The sending bank contacts the receiving bank to request the return of the funds. The receiving bank contacts its customer.

Step three. If the receiving customer confirms the mistake and agrees to return the funds, the recovery is straightforward. If the receiving customer does not agree or does not respond, the case moves through a defined AFCA process with escalation timelines and rules on the payer's recovery rights.

Consumer-side implication. Confirmation of payee is the front line defence. If you skip or ignore the name check, your recovery position under the mistaken-payment framework weakens materially. Read the confirmed name every time.

Name confirmation and the safe-harbour rule

Under current NPP participant rules and AFCA guidance, a bank that displays the confirmation-of-payee name and secures the customer's positive approval before releasing a payment benefits from a safe-harbour position on any subsequent mistaken-payment claim. The customer's confirmation transfers a portion of the responsibility from the bank to the customer.

Conversely, a bank that obscures or skips the name confirmation step does not benefit from the safe harbour. This is the specific regulatory structure that ensures every AU bank displays the confirmation-of-payee name prominently and requires a positive tap.

For customers, the take-away is that the name check is not optional user-experience friction; it is a substantive control that affects your own legal position on any subsequent dispute. Read the confirmed name every time, even for repeated payments to the same payee.

Payment initiation messages inside the bank app

The messages that flow between the bank app on your phone and the bank's backend are a separate topic from the NPP messages that flow between banks. Understanding both layers gives a complete picture.

App-to-backend messages typically use a REST or gRPC API secured with TLS 1.3 and certificate pinning. The bank's backend authenticates the customer using device-bound cryptographic keys held in secure hardware (Apple Secure Enclave, Android StrongBox).

The initiation message from app to backend carries the payee identifier, the amount, the reference and the customer's authentication. The backend then constructs the ISO 20022 pacs.008 message and sends it over the NPP network to the beneficiary bank.

The confirmation-of-payee flow happens between the customer's initial app request and the pacs.008 send. The bank's backend queries the Addressing Service, returns the resolved name to the app for the user's confirmation tap, and only then constructs and sends the pacs.008.

Overlay services beyond Osko and where they matter

Osko is the largest NPP overlay service by volume, but not the only one. Understanding the others helps situate PayID pokies flows in the broader payments landscape.

PayTo is an NPP overlay for account-to-account payment agreements, launched in 2022 and progressively rolled out across major banks. PayTo lets a merchant set up a recurring or one-off pull payment agreement with a customer, executed over NPP. It is designed to replace direct debits with a stronger consumer consent model.

The QR-Payments overlay allows payment initiation from a QR code. This is a technical foundation that could support merchant-scale contactless flows but has not yet reached mass consumer adoption in Australia.

For pokies specifically, none of these overlays are currently used at scale by offshore operators. The dominant flow is Osko-with-PayID because that is what the retail bank apps expose to consumers and what offshore gateways implement against.

NPP participants and how the platform is governed

NPP is governed by NPP Australia Limited (NPPA), a company jointly owned by the participating financial institutions of Australia. The RBA sits on the NPPA board and is the ultimate settlement counterparty through the Fast Settlement Service.

Participation is tiered. Direct participants (the major banks and a handful of regionals) connect directly to the NPP switch. Indirect participants connect through a direct-participant settlement bank. This tiering is common across international real-time rails; not every AU ADI runs the full NPP integration.

Governance covers technical operations, participant conduct rules, message specifications, dispute resolution and the roadmap for future overlay services. NPPA publishes participant rules and message specifications publicly.

Regulatory oversight sits above NPPA. The RBA under the Payment Systems (Regulation) Act 1998 has designation powers and access-regime authority. APRA supervises the participants. ACCC has competition jurisdiction over the collective ownership structure.

The near-term future of PayID in Australia

PayID adoption in Australia has grown steadily since launch and is now near-universal across retail bank apps. Recent focus areas include cross-border interoperability, PayTo integration and improved fraud controls.

Cross-border. Bilateral interoperability with New Zealand's real-time rail was scoped in a 2024 trans-Tasman announcement, with a phased implementation running through 2026. Broader connections into the Asia-Pacific real-time payment corridor sit in longer-term planning.

Fraud controls. The Scams Prevention Framework and the sequence of AFCA determinations since 2023 continue to shape mandatory bank controls on PayID payments. Expect steadily more friction on unusual first-time payments and on high-value transfers.

Identity. Trust exchange proposals under the 2024 Trust Exchange framework announcement could progressively reduce KYC friction across many use cases, including gambling deposits, by allowing federated identity assertions in place of document scans.

For pokies specifically, the trajectory is one of stronger AU-side controls and slower, safer flows. That is the correct direction for consumer protection even if it slows the wall-clock experience at the margin.