The vision for account-to-account payments in Australia

A2A vision > System characteristics  

4 System characteristics    

In order to consistently meet end-user objectives over time, the overall A2A payments system – that is, the products, services and infrastructure collectively used to process A2A payments – must demonstrate certain characteristics. These characteristics are also influenced by external factors that define both the opportunities and constraints within which the system operates. For example, technological advancements can provide new opportunities in the way end-user outcomes can be delivered but may also bring new risks that the system needs to address. Together, these characteristics are intended to meet current end-user needs, yet be flexible enough to support emerging use cases, technologies and operating models as those needs evolve over time.  

The six ‘system characteristics’ below identify what is required, subject to the relevant legal and regulatory obligations, to meet the end-user objectives outlined above: 

4.1 Secure and protected

A2A payments must protect funds, data, end-users and payments providers through robust and proportionate risk-based safeguards, supported by clear rules, technical standards and operational processes.

• The system and individual payment providers must incorporate safety-by-design through embedded preventative measures such as identity, authority and consent verification, payee validation, real-time fraud and scam detection, and Anti-Money Laundering and Counter-Terrorism Financing monitoring. These protections should operate across relevant transaction types (including inbound cross-border payments) and layers of the A2A payments ecosystem (including payment origination channels such as third-party platforms, enterprise systems and other authorised payment initiation models).
• The system should support integration with digital identity and authentication frameworks. The system should also ensure appropriate privacy protections, secure information sharing and strong data protection throughout the payment lifecycle.
• Fraud and scam prevention and response measures must align with applicable legal and regulatory obligations and frameworks (e.g. Scams Prevention Framework), evolving over time to reflect emerging risks and end-user expectations.  
• Payment mandates and authorisation, dispute resolution and liability arrangements must provide end-users with clear and consistent baseline protections, including defined responsibilities, timeframes and remedies, supported by transparent reporting, irrespective of whether payments are initiated directly by an end-user themselves or by an authorised system acting on their behalf.  
• System participants must collaborate to enable secure, standardised and high-quality fraud intelligence sharing, to detect patterns, coordinate responses to threats and strengthen collective defences over time.  
• Safety and security controls should balance risk-based friction and ease of use, allowing most transactions to proceed smoothly while applying targeted and proportionate friction on genuine threats.
• The system should align to relevant security standards (for example, in relation to tokenisation, encryption, cryptography, etc.).
• The system should support customer education initiatives that help users recognise scams, adopt safe behaviours and report incidents, reinforcing end-users' role as the first line of defence. 
  
  

4.2 Highly available and resilient 

A2A payments must be highly available with the risk of service disruptions addressed through a range of resilience measures, in-built redundancy, and clear contingency arrangements, in both normal and stressed conditions. Measures and arrangements must be aligned to system stability and national interest considerations to support the resilience of the economy.

• The system must be designed to achieve very high availability for processing A2A payment services (with real-time or deferred settlement options) through sustained and predictable operation, including during peak processing periods, and (where relevant) weekends and holidays.
• The system must be scalable and resilient, incorporating redundancy, failover mechanisms and sufficient capacity to handle current processing peaks and future volumes without degradation. 
• The system must have clear service level agreements in place, including for availability uptime, service performance and recovery times, which are developed collaboratively and aligned across the industry, are transparent and subject to regular resilience testing for defined scenarios.  
• The system must have robust contingency arrangements to maintain the provision of services during outages with clear industry-wide protocols and processes. These may include prioritisation of essential payment flows that support economic activity and public services (e.g. payroll and welfare), transaction queuing and retry mechanisms to ensure efficient recoverability following an outage. Contingency arrangements should include back-up payment processing arrangements that are sufficiently interoperable with, or substitutes for, normal arrangements. This may require an appropriate degree of compatibility or interoperability across data and messaging standards, payment instruction formats, routing arrangements and operational processes to enable alternative processing arrangements where required. Contingency arrangements must remain effective during transitions to alternate payment capabilities or technologies.
• The system’s resilience measures must strengthen the nation’s ability to reliably operate and protect the A2A payments system against external threats. This includes implementing appropriate security classification of critical A2A payments infrastructure, allowing government and industry to co-ordinate and respond to security concerns in a timely manner.
• The application and implementation of new technologies must be designed with resilience built in from the outset to ensure that new payment capabilities are secure, reliable and can scale safely. 
• The system should have transparent and regular publication of availability, service performance and resilience metrics that are consistently enforced to maintain industry and end-user confidence. 

4.3 Feature and capability rich  

A2A payments must support a broad range of payment functions, while enabling value-added features as end-user needs evolve over time and new technologies, business models and use cases emerge.

The following principles underpin a feature and capability rich A2A payments system. The system must: 

• Support the A2A payment types and use cases required by end-users, both today and into the future.  
• Support the core capabilities and features expected of the A2A payments system and provide a foundation upon which value-added capabilities can be developed in response to end-user needs as shown below. Section 8.2 provides further illustrative examples of how these capabilities may apply across the payment lifecycle.  
• Enable functionality, data and service capabilities to be tailored to the needs and requirements of different end-user cohorts, payment types and use cases.  
• Provide a modular and extensible foundation that enables capabilities, technologies and use cases to be incorporated over time without significant redesign.
• Support interoperability that enables capabilities, data and services to operate across different providers, platforms and evolving regulatory and technology environments, such as ledger-based forms of money. 

Examples of core and enhanced capabilities

Common capabilities - core functionality

• Structured and accurate payment information to support reconciliation and operational processes  
• Timely confirmation of payment receipt and outcomes  
• Integration with business systems including ERP and third-party platform providers  
• Exception handling e.g. returns, rejects and correction workflows  
• Ability for intended recipients to receive funds, including domestic and inbound cross-border payment flows

Common capabilities - enhanced capabilities

• Real-time payment confirmation  
• Open APIs for easy integration with business systems and other technologies  
• Payment status tracking with real-time notification  

Payments initiated by payers - core functionality

• Credit payments including one-off transfers e.g. instant person-to-person payments or bill payments  
• Scheduled payments for future processing  
• High-volume payment runs with predictable outcomes, e.g. reliable payment delivery and funds availability

Payments initiated by payers - enhanced capabilities 

• Alias-based addressing  
• POS, online and in-app payment integration  
• Enhanced processing of high-volume payments ('bulk') including rich structured data, payee validation, exception handling  

Payments initiated by payees or authorised third parties - core functionality

• Payment request functionality  
• Pull payment functionality e.g. direct debit, supported by appropriate authorisation, mandate management and revocation processes  

Payments initiated by payees or authorised third parties - enhanced capabilities

• Real-time validation of account and funds availability  
• Flexible mandates and payment agreements including variable amounts, frequency and expiry controls  
• Enhanced authorised pull payment experiences, including clear liability frameworks and robust dispute resolution processes 

As end-user needs evolve, features and capabilities that were initially considered enhanced may become core over time. System participants should collaborate, wherever possible, on the development and delivery of these capabilities, balancing commercial objectives with competition law. 

Structured data fundamental to enabling future A2A capability  

Granular structured data will be critical to support greater traceability and efficiency in reconciliation, regulatory compliance, stronger risk management and financial crime prevention. It also enables data to be tailored to specific payment types (e.g. superannuation, tax and inbound cross-border payments) and supports integration with emerging technologies – such as artificial intelligence – to unlock productivity gains.

The ability to integrate payments data into business systems and processes, including enterprise systems that originate payment instructions such as ERP, payroll and treasury platforms, will be key to supporting Australia’s digital transformation by improving payment quality, traceability and automation. Structured data also provides a foundation for a more modular A2A payment system, enabling new capabilities and services to be incorporated over time while maintaining interoperability across participants and platforms. 

4.4 Accessible for providers 

A2A payments must support broad access and participation arrangements, enabling different types of payment providers (including non-ADIs) to access clearing and settlement infrastructure and compete on terms that reflect their activities and risk profiles.

• To support a level playing field and effective competition and innovation, the system must include a range of access options that enable payment providers with varying business models and service types (including non‑ADIs such as PSPs, Digital Service Providers (DSPs) and fintechs) to connect to core A2A infrastructure, either directly or through a choice of intermediaries offering indirect access. Access to payment systems should also be accompanied by adequate representation in related governance processes.  
• Access and participation arrangements, including eligibility criteria and onboarding requirements, must be transparent and calibrated to the activity being undertaken and the risks introduced to the system. Onboarding and connectivity processes should be efficient and proportionate, including through the use of streamlined integration and connectivity approaches (e.g. standardised APIs, cloud-based connectivity models or other solutions), while maintaining appropriate risk controls. Unnecessary barriers, prohibitive entry costs or entrenched advantages for any class of participant are to be avoided.  
• Access and diverse participation must be balanced against the safety, security and stability of the A2A payments system. To manage this potential trade‑off, access frameworks should apply clear and proportionate financial, risk management, operational, compliance and technical requirements and assurance mechanisms, calibrated to the potential risks introduced by different types of providers and their activities. Access requirements may evolve as regulatory settings, such as licensing regimes, are refined over time.  

4.5 Commercially viable¹ 

A2A payments must support sustainable economic models for system participants, with competitive and transparent costs for participating and investing collaboratively. How commercial viability is achieved may vary across schemes, participant types, services and use cases.

• The system must be commercially viable for all relevant participants, taking into account infrastructure onboarding and connectivity costs, compliance and assurance obligations, ongoing operational costs (including transaction fees and charges), and investment in new or upgraded capabilities (including implementation costs).  
• Total costs for participants should be weighed against realistic commercial incentives for developing and delivering A2A payment services, so that they can justify investment.
• Various fees, charges and other costs for participants should be clear and transparent, and where possible, predictable.
• Governance and decision-making rights should be aligned to funding and investment contributions and risk borne by participants, including for determining investment priorities, developing capabilities and applying requirements, whilst considering other stakeholder perspectives. At the same time, governance mechanisms, pricing models and commercial frameworks should support a range of participants and business models (including smaller providers), enabling differentiated propositions and avoiding structures that entrench market power or limit contestability.  
• Technical and operational simplicity in the design of the payment system should be prioritised where possible, recognising that simplicity can reduce costs, improve efficiency and support reliability.   

4.6 Appropriately standardised 

A2A payments must achieve an appropriate degree of standardisation through the application of common rules, requirements, formats and processes. Standardisation should focus on areas of the system where fragmentation would undermine safety or reliability, or where consistency, interoperability and the achievement of network effects would generate broad benefits. These benefits can be both within a particular payment scheme or service, or across multiple payment schemes.

Standardisation within the A2A payments system can help to:  

• Create network effects, to the benefit of all stakeholders.
• Strengthen resilience, security and user protection by minimising the creation of risks through inconsistencies.  
• Support innovation and competition by reducing complexity, entry and ongoing maintenance costs for providers and platforms.  
• Increase the consistency of user experiences, regardless of provider, and reduce costs faced by end-users when seeking to switch service providers and when porting payments data.
• Assist regulators to oversee the system more effectively. 

Some aspects of A2A payments that meet this framework for appropriate standardisation are discussed below:

• The benefits of standardisation need to be balanced with not unduly constraining competition and innovation, given excessive standardisation could inhibit payment providers’ flexibility to compete and offer differentiated products and services.
• Standards should be applied and adhered to at the appropriate layer (industry-wide, scheme or product), supported by a clear framework for where and how standardisation should be applied.
• Standards should be developed and maintained through industry collaboration, complemented by regulatory oversight where appropriate. Clear and transparent mechanisms for prioritisation, consultation and periodic review will ensure standards remain adaptable to technological change and market needs without unnecessarily constraining competition and innovation.  
• Consistency with international and economy wide standards should be realised where appropriate, including alignment with relevant open standards and interoperable protocols for digital infrastructure. 

Areas for appropriate standardisation 

Data, payment and integration 

• Industry must: align on standards for payment messages including data elements and field definitions, lifecycle states and status codes for payment types, minimum formats for integration, e.g. standard payment instruction format, data protection and handling.  
• Industry should: align on standards for processes (e.g. reason codes for payment returns, refunds and disputes) and API specifications.  

Trust, identity and security 

• Industry must: develop standard approaches for payer authentication and payee name and account validation, and security models; baseline controls for fraud monitoring, anomaly detection and scam intervention, including minimum information to be shared for system-wide intelligence.
• Industry should: consider the use of alias-based addressing to support ease of use and reduce payment errors, align on common incident severity classifications, notification expectations and response-time benchmarks.  

User experiences and protections 

• Industry must: align on UX standards for critical journeys including terminology and accessibility expectations, define a baseline level of consumer protection for A2A payment experiences. 
• Industry should: develop standards where appropriate to support seamless use of A2A payments within end-users’ digital workflows.  

4.7 Alignment of system characteristics to end-user objectives 

An overview of how these six system characteristics support the end-user objectives outlined in Section 3 are discussed below highlighting that multiple system characteristics can support a single-end user objective and each characteristic may contribute to multiple end-user outcomes. For example, appropriate standardisation can, in principle, be a means to facilitating achievement of each of the five end-user objectives (see 4.6). Similarly, new capabilities can be used to support various end-user objectives.

However, tensions between some end-user objectives and system characteristics may limit the extent to which end-user outcomes can be fully realised together, at least in the short term. Delivering improvements in one area may require trade-offs in another, requiring careful prioritisation and balancing of competing objectives. Such tensions are inherent in payment networks. For example, broad access and diverse participation can drive stronger competition and innovation, and in turn end-user outcomes. However, wider participation might introduce risks, which unless carefully managed, could adversely impact the integrity and stability of the A2A payments system as well as end-users’ experiences and trust.  

Similarly, there may be a trade‑off between keeping providers’ costs and end‑user prices low, and the commercial sustainability of delivering a modern, capability‑rich, secure and resilient A2A system. To manage this, industry and stakeholders should define which features are ‘core’ that deliver baseline service quality, broad public benefits and underpin trust. 

• For core features and capabilities, the industry should collaborate and, where appropriate, self‑regulate development and delivery of these features, with clarity and transparency about required investments, who contributes, and how the resulting benefits are distributed across providers and end-users.
• For enhanced capabilities, the industry should consider collaboration and coordination where it is in the collective interest for all (for example at the infrastructure level). Where that does not apply, the system should be left to competitive market dynamics, allowing providers to differentiate on functionality, service levels, end-user pricing and other commercial terms while still meeting any baseline safety and reliability expectations. 
  
  

Potential tensions arising in the pursuit of the system characteristics and end-user objectives will be addressed as part of the prioritisation and sequencing of deliverables under the A2A payments roadmap, taking into account the principles outlined following.  
 
System characteristics to support end-user objectives 

Secure and protected, supports the following end-user objectives: 

• Safe
• Reliable

Highly available and resilient, supports the following end-user objectives: 

• Safe
• Reliable
• Inclusive

Feature and capability rich, supports the following end-user objectives: 

• Safe
• Reliable
• Affordable
• Easy to use
• Inclusive

Accessible for providers, supports the following end-user objectives: 

• Safe
• Reliable
• Affordable
• Easy to use
• Inclusive 

Commercially viable, supports the following end-user objectives:

• Safe
• Reliable
• Affordable 

Appropriately standardised, supports the following end-user objectives: 

• Safe
• Reliable
• Affordable
• Easy to use
• Inclusive

[1] The commercial viability concept relates to entities supplying payments services, including schemes, financial institutions and PSPs. Costs for end users are considered separately in Section 3.3.