NPP Overlay Services & AFSL Obligations: A Developer’s Guide

Introduction

The New Payments Platform (NPP) provides a data-rich, real-time payments infrastructure that serves as a cornerstone for innovation in the Australian financial system. For developers and fintechs, creating an overlay service involves balancing technical integration with NPP Australia standards and the legal mandates of the Corporations Act 2001 (Cth).

This guide provides a strategic overview for overlay service providers to align their technical builds with Australian Financial Services Licence (AFSL) obligations. By addressing heightened fraud and liquidity risks from the design phase, teams can build resilient payment services that meet the rigorous standards of the evolving licensing framework.

NPP Overlay Service: Rules & Legal Requirements

Defining an NPP Overlay Service

An NPP overlay service is a commercial payment or payment-related product that is built on top of the NPP’s core infrastructure. These services use the NPP’s fundamental capabilities to create customised payment experiences for users, including:

• ISO 20022 messaging.
• PayID addressing service.
• Real-time settlement via the Fast Settlement Service (FSS).

The first and most prominent example of an overlay service is Osko by BPAY, which facilitates instant, data-rich payments between individuals and businesses. The design of the NPP allows for the development of multiple overlay services, fostering innovation and competition by enabling new payment solutions without altering the underlying platform.

The NPP Technical & Scheme Layer

Developers must conform to a set of technical standards and scheme rules governed by NPP Australia Limited (NPPA). These requirements ensure that any new service operates securely and does not compromise the integrity or stability of the national payments infrastructure.

The technical obligations for an overlay service provider include:

• Messaging Standards: Adherence to the ISO 20022 messaging standard is mandatory, allowing for data-rich payments capable of carrying up to 280 characters of remittance information.
• Gateway Integration: Services must connect to the NPP network through a certified Payment Access Gateway (PAG) to securely route transaction messages between the provider, financial institutions, and the central infrastructure.
• API Framework: NPPA provides a standardised API framework to streamline development, including specifications for critical functions like payment initiation and PayID resolution.

Beyond the technical integration, providers must also comply with scheme rules and undergo a formal onboarding process. This involves submitting an application to NPPA, which assesses the applicant’s business plan, technical expertise, and financial solvency.

Once approved, an Overlay Service Provider (OSP) must adhere to the NPP Regulations and Procedures, which contractually bind all participants.

The Legal & Regulatory Layer

Operating an NPP overlay service often triggers legal obligations under the Corporations Act 2001 (Cth), which are enforced by the Australian Securities and Investments Commission (ASIC). This means that in addition to NPPA’s rules, developers must navigate Australia’s financial services laws.

A key consideration is whether the service constitutes a “non-cash payment facility.” If an overlay service allows users to make payments other than by physical cash, it is likely to be classified as this type of financial product, which requires the provider to understand the rules around dealing in a financial product and hold an AFSL.

Furthermore, upcoming regulatory reforms are set to make these obligations more explicit. The Australian Treasury has proposed a new licensing framework that will introduce specific categories of regulated payment functions.

A crucial new category is the “payment initiation service,” defined as the initiation of payments from a payer to a payee by a third party at the customer’s request. This definition is expected to clearly capture most NPP overlay services, reinforcing the need for an AFSL.

AFSL Authorisations for Real-Time Payments

Identifying Regulated Payment Functions

An overlay service that enables users to move money in real-time will often perform one or more functions that are regulated or are proposed to be regulated.

Developers should analyse their service’s features against these payment functions to understand their likely licensing obligations.

The proposed regulatory reforms introduce specific categories of financial services that are likely to capture most NPP overlay services.

Key payment functions that may require an AFSL include:

• Payment Initiation: This involves a third party initiating a payment from a payer to a payee at the customer’s request. This function directly applies to services that trigger NPP transfers, such as “pay anyone” features, e-commerce checkouts using stored mandates, or Request-to-Pay flows.
• Payment Processing: This function is relevant where the overlay service routes, authenticates, and authorises NPP payment instructions on behalf of merchants or other payment service providers.
• Digital Wallet or Stored Value: If the overlay service holds value for customers or operates as a digital wallet linked to NPP-enabled accounts, it falls into this category.
• Authentication and Addressing: A service may be captured if its primary value is providing authentication, directory services, or risk scoring that is essential to the execution of a payment.

Securing the Correct AFSL Authorisations

Under the current framework, an overlay service that facilitates payments is typically classified as a non-cash payment (NCP) facility under the Corporations Act 2001 (Cth).

This classification typically triggers the need to obtain an AFSL with the correct authorisations.

As the regulatory landscape evolves, these authorisations are becoming more function-specific.

The AFSL authorisations most relevant to NPP overlay services include:

• Providing a non-cash payment facility: This is the primary authorisation under the current regime for services that allow users to make payments without the physical delivery of currency.
• Dealing in a financial product: This is required if the overlay service is involved in issuing or arranging to issue the NCP facility, particularly where it defines the product’s terms and conditions.
• Operating a registered scheme or custodial service: This authorisation may be necessary if the overlay service pools customer funds, holds money in trust accounts, or otherwise interposes itself in the settlement flow, as this may be considered a custodial or depository service.

When reviewing AFSL applications for NPP-based services, ASIC expects to see detailed explanations of how the unique risks of real-time payments are managed.

This includes demonstrating robust systems for:

• Onboarding and identifying clients in line with Anti-Money Laundering (AML) and Know Your Customer (KYC) requirements.
• Monitoring transactions in a 24/7, high-velocity environment to detect and prevent fraud.
• Managing disputes, error recovery, and fraud remediation, acknowledging the low reversibility of real-time NPP payments.

PayID Management & Fraud Liability for Your Service

How PayID Works & Who Is Responsible

PayID is an addressing service for the NPP that allows customers to link a simple identifier to their bank account. This includes options such as:

• A phone number
• An email address
• An ABN

This feature simplifies the payment process by removing the need for payers to enter BSB and account numbers. A critical security feature is the “confirmation-of-payee” step, where the NPP returns the legal name of the account holder for the payer to verify before authorising the transfer.

The responsibility for misdirected payments depends on the source of the error. Consequently, the liability framework distinguishes between two main scenarios:

• Mistaken Payments: If a user authorises a payment after viewing the correct payee name but made a mistake, such as by entering the wrong PayID, the user typically bears the loss. However, financial institutions are generally required under the ePayments Code to assist in recovery efforts.
• Misdirected Payments: If a payment is sent to the wrong account because a financial institution incorrectly registered the PayID information, that institution is responsible. Under NPP Regulations, the registering participant must indemnify the payer’s bank for any loss resulting from such an error.

Designing Your Overlay Service for PayID Compliance & Fraud Prevention

For developers of an NPP overlay service, integrating PayID functionality requires careful design to manage fraud risks and meet AFSL conduct standards. Your user experience (UX) and API flows must align with the verification and name-display rules set by both NPPA and the participating financial institutions.

Failing to properly display the confirmation of payee screen could shift liability for a mistaken or fraudulent payment from the bank to your overlay service. From an AFSL perspective, your compliance program must treat PayID resolution as a critical control point. This involves implementing several key measures:

• Robust Verification and Logging: Your system should include detailed logging of all PayID lookups and display clear confirmation screens showing the payee’s name to the user before final approval.
• Fraud and Risk Controls: Integrate real-time fraud detection, risk scoring for unusual activity, and transaction monitoring to identify and flag suspicious patterns.
• Dispute Resolution Policies: Establish clear policies for handling mistaken internet payments and scams that align with the ePayments Code and ASIC’s internal dispute resolution requirements, which typically includes the requirement for Australian Financial Complaints Authority (AFCA) membership.
• User Education: Implement clear warnings and educational prompts within your service’s interface to inform users about common payment scams and how to verify payment details.

Liquidity Management for 24/7 Real-Time Settlement

How NPP & Fast Settlement Service Works

The NPP utilises the Reserve Bank of Australia’s (RBA) FSS to process transactions. This system settles each payment individually in central bank money, operating in near real-time on a 24/7 basis.

This approach provides immediate and irrevocable finality for every transaction, ensuring that:

• Funds are debited from the payer’s institution.
• Credits are applied to the payee’s institution simultaneously.

This continuous settlement model means there are no traditional cut-off times or batching processes. Consequently, NPP Participants are required to hold sufficient balances in their Exchange Settlement Accounts (ESAs) at the RBA.

They must actively manage their intraday and overnight liquidity to ensure funds are always available to cover payment flows:

• Outside of standard business hours.
• On weekends and public holidays.

Liquidity & Risk Management Obligations for Overlay Providers

Even if an overlay service provider is not a direct NPP Participant, regulators expect it to manage the liquidity and settlement risks associated with real-time payments. When applying for an AFSL, providers must demonstrate to ASIC that they have robust systems in place.

ASIC expects to see detailed policies and contingency plans that address these unique risks. Key requirements for an AFSL application include:

• Stress Testing and Scenario Planning: The provider must show evidence of stress testing its systems to handle events like significant spikes in transaction volume or liquidity shortages.
• Contingency Plans: There must be clear plans for managing outages, whether they originate from the RBA, NPPA, or key banking partners. This includes having cut off or throttling rules for when settlement channels fail.
• Funding and Liquidity Buffers: Providers should demonstrate clear policies on funding arrangements, such as pre-funding accounts or maintaining standby credit lines, as part of their broader financial requirement obligations as an AFS licensee. This is particularly important for services that operate pre-funded wallets or hold client money in trust accounts.
• Incident Response: A 24/7 incident response plan is necessary to manage issues and communicate with customers, acknowledging that payments and potential scams can occur at any time.

Strategic AFSL & Design Considerations for NPP Developers

Mapping Your Overlay Features to Regulated Payment Functions

To determine the scope of your regulatory obligations, you must analyse your overlay service’s features against the proposed payment functions outlined by the Treasury.

This process involves mapping each component of your service to a specific regulated activity to understand your likely licensing requirements.

Treating compliance as a design constraint from the outset is crucial, rather than addressing it after development.

Key payment functions that are likely to bring an NPP overlay service within the new licensing framework include:

• Payment Initiation: This applies if your service allows end-users to start an account-to-account payment. Examples include “pay anyone” features, e-commerce checkouts that use a stored mandate, or services that facilitate Request-to-Pay flows.
• Payment Processing or Gateway Functions: Your service may be captured if it routes, authenticates, or authorises NPP payment instructions on behalf of merchants or other payment service providers.
• Digital Wallet or Stored Value: If your overlay service holds value for customers or operates as a digital wallet linked to NPP-enabled accounts, it will likely fall into this regulated category.
• Authentication and Addressing: A service may require licensing if its core value proposition involves providing authentication, directory services, or risk scoring that is integral to the execution of a payment.

Choosing Your Licensing Pathway

Once you have mapped your service’s functions to regulated activities, you must decide on a strategic licensing pathway.

There are several options available, each with different operational and compliance implications.

The choice depends on your business model, resources, and long-term objectives.

The primary strategic options include:

• Holding an AFSL directly: This pathway involves going through the AFSL application process to get and maintain your licence with authorisations that align with your specific payment functions. While this provides the most autonomy, it also carries the highest regulatory and compliance burden.
• Operating as an authorised representative: You can choose to operate under the AFSL of another licensee, a model often referred to as an AFSL for hire. This allows you to provide regulated services without holding the licence yourself, but you will be subject to the oversight and compliance framework of the primary licensee.
• Designing the service to minimise regulated functions: A third option is to structure your service in a way that avoids triggering the most significant licensing requirements. This approach requires careful legal and technical design to ensure your service remains outside the regulatory perimeter while still complying with NPPA and RBA expectations.

Building Compliance into Your Application & Documentation

When preparing an AFSL application, it is essential to build compliance into your documentation from the ground up.

ASIC expects to see a clear and comprehensive articulation of how your service manages the unique risks associated with real-time payments.

Your application must demonstrate that your technical build and operational frameworks are aligned with your AFSL obligations, a task where guidance from experienced AFSL lawyers is invaluable.

Your application and supporting documentation should include:

• Real-time fraud and scam controls: Clearly describe your measures for managing fraud, particularly concerning PayID usage. This includes details on behavioural analytics, transaction monitoring, and customer education initiatives designed to prevent scams.
• Governance and risk frameworks: Provide detailed frameworks explaining how your service manages 24/7 liquidity, operational resilience, and dependencies on third parties like NPP Participants and cloud service providers.
• Liquidity and settlement management: Document your liquidity model, including 24/7 settlement forecasts, pre-funding arrangements or intraday credit facilities, and the results of stress tests for peak transaction volumes.
• Integration of scheme and legal obligations: Show an explicit link between your obligations under NPPA scheme rules and your general obligations as an AFSL holder. This demonstrates to ASIC that scheme compliance is an integrated part of your overall risk management system.

Conclusion

Building an NPP overlay service requires developers to integrate NPPA’s technical rules with the legal obligations of the Corporations Act 2001 (Cth) from the initial design phase. Successfully launching a compliant real-time payment service depends on proactively managing the unique fraud, liability, and liquidity risks inherent in a 24/7 settlement environment.

To navigate these complex requirements, securing expert guidance is essential for aligning your technical build with your AFSL obligations. Contact AFSL House’s expert AFSL compliance lawyers today to leverage our trusted expertise in AFSL applications and tailored compliance frameworks, ensuring your payment service is built on a resilient and compliant foundation.

Frequently Asked Questions (FAQ)