Throughout 2018 we have gradually seen more ADIs providing their customers (or members) with the ability to make payments through the New Payments Platform (NPP). Commonwealth Bank of Australia and a large number of Mutual Banks and Credit Unions such as The Mac were the first to go live, however we have now seen all the major banks provide access for their customers to the platform.
While access to date has been mainly for retail customers (Mums and Dads), it is important for Corporate Australia to recognise the benefits that the NPP can give them. As the NPP begins to accept larger payment sizes it will be possible for large customers who would normally settle by Real Time Gross Settlement (RTGS) to move to the NPP. The NPP is significantly faster, cheaper and more reliable than making a settlement through RTGS.
In addition there are further potential advantages for Corporates. Corporates typically release payroll payments a working day before they fall due, resulting in a funding cost of anywhere up to five additional days. There is good reason for this: payroll is typically paid via Electonic Funds Transfer (EFT) which settles overnight. That means if there are any problems in the payment process the payroll team can still correct it the following day and still pay their employees on time.
However because NPP payments settle in true real time, it would now be possible to schedule a payment in the early morning on the day the payroll falls due. This saves the additional funding days whilst still allowing a payroll team to have multiple opportunities throughout the day to correct the payments if there are any problems. Employees still have access to their money at the same time, but the interest benefit flows to the Corporate.
The following example shows how a much an NPP payment would be worth to a Corporate who moves from releasing a payroll payment ahead of the contractual minimum to the actual day. In this example as long as the NPP payment didn’t cost 68c more than the current EFT payment then a saving will be made.
There is still one uncertainty in this process however. Many of the banks are still determining what they will charge corporate customers for NPP payments. It will be more expensive than an EFT payment but hopefully a combination of the potential interest savings plus the ability to send payslips electronically would compensate for some of this cost. In addition the more Corporates who move to making payments by the NPP, the more that the banks will be able to pass on the volumetric savings to their customers. Hopefully a win for everyone concerned.
It is now time for Corporate Australia to start thinking about how they can make the NPP work to their advantage. However to truly extract the benefits, it will be necessary for them to start working with their software providers to automatically transmit electronic payment files to their bank. This will involve requiring the software provider to start programming the NPP payment format file ISO20022 so that it can be sent directly to their bank. The objective of this article is to try and show how easily this can be achieved.
Until now, employees or suppliers have always provided BSB and Account Number in order to be paid. However now it is possible to use a PayID to pay to a customer (see below for the different options). To be able to offer the full functionality of the NPP payments, systems will need to be adapted to capture PayIDs as an alternative to BSB and Account No.
The precise format of how each bank will make this file work are still being finalised. However for this article I am choosing to use ANZ’s file format. Why? Simply because ANZ were the first bank to make the format available. My aim here is simply to show how the ISO20022 file works and how good that file format is. Hopefully that will give all Corporates the incentive to start talking to their own bank and beginning development of their files.
For those of you familiar with either the standard Australian Bankers’ Association (ABA) file format for EFT payments or even the SWIFT MT101 message, the ISO20022 file is completely different. It uses an XML format. While this does make for a much longer message, each line of data is wrapped between a tag opening <tag> and a tag closing </tag>. This gives complete certainty over the data – no more having to line up an exact number of characters on a single line or concatenate multiple fields together.
To get the best out of the rest of this article, I suggest that you download an Excel file which I have created which easily turns standard payment data into the required XML format at the click of a button. Remember that the NPP gives four different payment options, and one ISO20022 file caters for all of them:
- Pay to a standard BSB and Account Number combination
- Pay using a Pay ID which can be
- A registered e-mail address
- A registered mobile phone number
- A registered organisational ID such as an ABN
The file is an xlsm file – ie an Excel file which contains macros. That macro (Output_XML) will create an ISO20022 file when run. There are a few things that you need to do before running the macro for the first time:
- Ensure that macros are enabled
- Add a valid directory on your PC in cell B8 to output the file to
- If you want change the name of the file change cell B8 (keep the .txt file extension)
- If you want to output a different file each time with a datestamp then change cell B10 to Yes
To run the file, simply click on the Output XML button at the top of the page. A full output file to the directory and filename specified. By being able to play around with and manipulate the file you can get a sense of how ISO20022 works.
It is noted that this is the first draft of a file format and may be subject to change in the future as functionality develops. Note given that ISO20022 for NPP is very much in its infancy, it has not been possible to test that the spreadsheet works totally correctly. It is merely designed as a learning tool to show how easy this can be developed, so that Corporates gain the confidence to go and look at this as a project with their own bank.
ISO20022 for NPP has four core components to the file structure. The remainder of this document will make most sense if read in conjunction with using the spreadsheet.
A. The Group Header <GrpHdr>
This is fairly routine and contains information about the whole file such as a message ID with the creation date and time of the file. The key part of the file is the number of payments to be processed (<NbOfTxs>) and the batch total of all the payments in the file (<CtrlSum>). The ANZ file format also contains an additional line around authorisation of the transaction (<Authstn><Prtry>) which allows the file to either be authorised in internet banking or allow straight through processing.
The static variables are contained in rows B12-15 of the spreadsheet.
B. Payment Information <PmtInf> split into three parts
Part 1. Further information about the transaction
There is some repetition of information here such as the batch totals and payment numbers, however a unique reference is required for the file (<PmtInfId>). The key field here is the ability to set a value date for the file to be processed (<ReqdExctnDt>).
The static variables are contained in rows B17-22 of the spreadsheet. Requested Execution Date is the only non-static variable.
Part 2. The bank account to be debited <DbtAgt>
The bank account to be debited is contained within the tags <DbtAgt> with the key fields being BSB and Account Number.
The static variables are contained in rows B25 to B29. Note it would appear that only one bank account can be debited in each file.
Part 3. The payments to be made <CdtTrfTxInf>
One <CdtTrfTxInf> tag (open and close) is required per payment.
Each payment requires a unique transaction reference (<InstrId>) in the spreadsheet I have done this by putting a combination of date and time with a transaction number, however if programming in an ERP or treasury system this would likely be able to have their own unique reference which could be replicated.
The amount to be paid is in the <Amt> tag. The only currency available in the NPP currently is AUD, so the second tag can read <InstdAmt Ccy = “AUD”> then the Amount in dollars and cents.
The final part is the information about the creditor themselves. This is the only part which varies according to whether BSB/Account number of PayID is being used.
For BSB and Account Number payments the BSB goes in the <FinInstnId> tag with the account number in the <CdtrAcct> tag.
However where a PayID is used the only information required it the PayID itself and the type of PayID being used using the <CtctDtls> tag. For example where an e-mail address is used the tag if <EmailAdr> and then the type of PayID is shown between the <Othr> tag.
When using the spreadsheet, the variable data used for each payment begins at line D7 and goes through to line D21.
Although the ISO20022 file appears to generate a very long file just to make a single payment, it contains excellent flexibility thought the use of XML. The functionality of this file is also adaptable in that new tags can be added in the future.
Given the benefits of the NPP, I would recommend that Corporates start to consider the benefits of using the NPP to make all payments. It will take time to plan this out and time is still required for the NPP to increase volumes and transaction size, however given the functionality this is an investment that all Corporates should start to make.
About the Author
Alistair McLean is a former Non-executive Director of The Mac (a credit union who implemented the NPP on day one) and the former Group Treasurer of Metcash Limited. Alistair is currently taking a [very] short break between jobs. Alistair is a Fellow of the Association of Corporate Treasurers, a Fellow of the Finance and Treasury Association, a Chartered Management Accountant and a Graduate of the Australian Institute of Company Directors.