- SAP Managed Tags
Welcome to the second installment of the Blog series on the New Payments Platform (“NPP”) in Australia.
The series is planned as:
- Unlocking the NPP: SAP Capabilities for Faster, Smarter Payments
- Unlocking the NPP: Payments overview
- Unlocking the NPP: PayID
- Unlocking the NPP: PayTo
In the previous Blog we described the capabilities of the NPP and provided a brief insight into how SAP delivers these.
In this Blog we’re going to dive into some of the details around file formats and Bank integration as these underpin the process. As mentioned in the previous Blog, each Bank defines their file format and contents so you will need to check these when building your specific solution.
Payment Format basics
I’m going to assume a working knowledge of SAP Payment processes, formats and integration but some of the terminology warrants further explanation.
NPP is built around files or messages (and I’ll use the terms interchangeably) based upon ISO20022 which is:
“A single standardisation approach (methodology, process, repository) to be used by all financial standards initiatives” and “a multi part International Standard prepared by ISO Technical Committee TC68 Financial Services. It describes a common platform for the development of messages”.
For our purposes we just need to understand that ISO20022 defines numerous message types and their formats. The main message types SAP will be creating are the Payment Initiation (“pain”) formats:
- pain.001 Customer Credit Transfer Initiation
- this is the typical outgoing payment bank transfer
- includes payments to BSB / Bank Account and to PayID (OSKO ID)
- also support Direct Debits with PayTo Agreement
- latest version V12 – pain.001.001.12
- pain.008 Customer Direct Debit Initiation
- this is the request to collect from a Customer’s bank account
- includes collections from BSB / Bank Account and with PayTo Agreement
- latest version V11 – pain.008.001.11
SAP standard content
So what does this mean in SAP? We maintain payment file formats in the Data Medium Exchange Engine – in SAP ECC this is transaction DMEE, in S/4HANA we have DMEEX (Extended) whilst in Public Cloud we use app “Create Payment Medium Formats”. I’m not going to discuss the older RFFO* programs which required ABAP coding to manage the formats.
The payment file formats manage the file structure (header and item levels, field names and definitions etc) and the field contents. Contents can be hardcoded, mapped from SAP Payment structures (FPAY* tables) or flexibly derived through coding.
The ISO formats are delivered by SAP with a prefix CGI (Common Global Implementation) and you should see these in your S/4HANA system:
- AU_CGI_XML_CT CGI Credit Transfer for Australia
- This equates to the pain.001 format
- AU_CGI_XML_DD CGI Direct Debit for Australia
- This equates to the pain.008 format
You may wonder why there is an Australian version of a global standard. One example is the use of the combination of BSB and Account number to manage Bank details for Payer and Payee, rather than just a single identifier such as an IBAN.
The latest published ISO pain.001 files version is 12 whilst the delivered SAP S/4HANA content is version 06. We are investigating when and how to release updated content for all file types. This is not an urgent requirement as Banks and NPP do not adopt the latest version immediately on release and updates can be configured as required.
In addition to the Australian versions of the ISO format, there are some generic formats delivered which may be useful as a reference:
- S/4HANA
- CGI_CT CGI Credit Transfer
- CGI_DD CGI Direct Debit (Automatic Debit)
- ECC (including Success Factors Employee Central Payroll)
- CGI_XML_CT
- CGI_XML_DD
Versions and Bank formats
In the previous Blog we described how SAP interacts with Banks who are connected to the NPP.
The Payer’s SAP system will create a payment file in the format required by the Bank. This may be in older ISO format (or variant) or another format.
The Bank validates this within their internal system and creates a pacs.008 Customer Credit Transfer – Clearing Request which is sent to the NPP to make the payment.
A quick review of the Big 4 Banks’ publicly available information on file format and mapping shows:
- 2 mention pain.001 version 03
- 1 mention ABA / DE (BECS) format
- 1 has no specific NPP information
Just sending a pain.001 ISO format file to the Bank does not automatically mean that it will be processed through the NPP rather than BECS. Each Bank may use different fields in the file to determine the processing channel (i.e. NPP or BECS) and these may entail use of existing “proprietary” (customer defined) fields. Banks can receive other formats, including NPP specific fields such as PayID (OSKO) and map the contents internally prior to sending to the NPP
The upshot of all this is that each SAP Customer will need to check with their Bank on formats, field content and data mapping to ensure files are processed correctly. Whilst there is a perception that everyone needs to move onto ISO20022 formats in readiness for the eventual shutdown of the BECS clearing system, the timeframe is dictated by the Banks who determine their required format. Note that the previous direction that BECS would close in 2030 has been removed and no new date announced.
As mentioned in the previous Blog, SAP’s strategic direction is to provide solutions based on common standards but not the Bank specific variations. Customers will therefore always require some additional customization to adjust the delivered standard content.
SAP Bank Integration
NPP does not require any specific changes to Bank integration and the typical legacy point to point integration can be retained. However, SAP recommends Multi Bank Connectivity (“MBC”) combined with as the future state for NPP.
MBC already provides benefits around a managed integration service with visibility and control of the payments files. In the context of NPP it’s worth bearing in mind that the volume and frequency of “traffic” to and from the Bank is likely to increase. Each Payment Header and Item will trigger three incoming messages (File accepted, Pending and Transaction Processed / Rejected). Customers may change the frequency of outgoing payments, for example moving from a batch driven weekly run to daily or even real-time activity. With the NPP operating 365 days a year, payments can be scheduled on weekends or Public Holidays. This allows payments exactly according to payment terms (but not early), enabling access to settlement discounts and improving cash flow.
Similarly Incoming payments are usually only visible in the Bank Statement received the following day. As customers move to NPP for incoming payments and want to adopt flexible business models, such as processing sales or deliveries on receipt of funds, there is a requirement to handle real time incoming payment messages or intraday bank statements.
The combination of MBC and BCM provides a solution for bank integration suited to both real time processes and detailed logging of the inbound and outbound flows, as well as monitoring the status of payments and resolving errors.
MBC Member Banks can offer their APIs to SAP customers, enabling enhanced real-time capabilities while maintaining the security and reliability of the SAP Multi-Bank Connectivity platform. Some of the additional capabilities of the NPP such as PayTo Agreements (as the successor for Direct Debits) assume usage of APIs and sample files and flows are available from Australian Payments Plus (as the owner of NPP) as well as from Banks. Where a customer implements an API outside of MBC, they are responsible for all aspects of build and operation, including middleware, encryption and monitoring.
NPP payments – the basics
Let’s assume we are working with a Bank which requires the pain.001 Version 003 file with a couple of specific field mappings.
Firstly, you should create the Bank specific version as a Child Tree of the standard format in DMEEX.
This new Format can be edited as required to meet the Bank specific Version, Format and Mapping details.
For example, the Bank requires “<PmtMtd>” as “TRF” and “PmtTpInf><LclInstrm><Prtry>” as “X2PI” for a file to be processed with NPP (OSKO). This can be achieved with simple use of Constant in the DMEEX configuration.
Other mapping is possible with an understanding of how the information flows into the standard Payment file structures – refer this Blog and related note:
Source of Information for Field in structures FPAYH-FPAYHX-FPAYP
Further flexibility is possible using BAdI FBL_EVENT_06 which enables population of ZREF01-ZREF10 fields which can then be mapped to the DMEE fields.
The Payment Format needs to be assigned to the Payment Method in "Set up Payment Methods for Each Country/Region for Payment Transactions" configuration.
You may consider defining new NPP specific Payment Methods. This is not mandatory but does provide a clear way to execute separate Payment Runs and Payment Files for BECS and NPP. For some Banks, the Payment Channel (NPP or BECS) is defined at the File header level.
You are also able to define whether the Payment Method can continue to work with BSB and Bank Account numbers from the Business Partner master or if PayID details are required (see next Blog).
The Payment Run execution, Payment File creation and transfer to the Bank follows the existing processes.
Incoming messages for payments
The Bank will send three status confirmation messages using the pain.002 format. How these are handled depends on your setup:
- SAP BCM enables receipt and reporting of the incoming messages. This has integration back to the original payments and enables error handling through the reversal of the outgoing payment document and reset of open items, allowing a new payment to be created.
- SAP MBC provides message viewing and forwarding capabilities
- Custom built solution to store and view files as part of custom bank integration
- No SAP solution, with potential to view in Bank portal
Bluesky| User | Count |
|---|---|
| 12 | |
| 6 | |
| 6 | |
| 6 | |
| 4 | |
| 4 | |
| 3 | |
| 3 | |
| 3 | |
| 3 |
