XML payments are increasingly becoming – if not already – THE global standard format for corporate to bank payments. There are many reasons for the growing XML adoption rates and in this post i thought i would explain 10 of the key benefits of XML payments.
XML Payments – A Quick Introduction
Regular readers of this blog will know that i have talked about XML quite a bit already. If you’re not sure what XML is take a read of SEPA XML in a nutshell and Understand ISO 20022 XML In Less Than 2 Minutes. In those 2 posts i provide an overview of XML (eXtensible Markup Language) with a focus on ISO20022 XML which is the global standard for financial messaging. In these posts i delve into ISO20022 XML as a international dictionary for financial messaging, which the industry globally refers to and has agreed the overall base format and XML structure for payment processing.
XML Payments – The Benefits
In no particular order:
1. XML Payments Are Used Globally
The key benefit here is that once you have developed the XML format for payments, then you have done the bulk of the hard work and can re-use most of that created XML payment format elsewhere. For example, once you have created a SEPA compliant payment or direct debit format you have in that ONE format a solution for making payments to suppliers or direct debiting customers across the WHOLE of Europe. Previously to make payments in the 17 Euro-zone countries would have required at least 17 different payment formats – now you need just 1. For direct debits you have 1 format, with slight variations depending on the type of direct debit you choose.
Similarly, the created XML payments format can be tweaked and amended to handle payments globally – for example across countries in Asia-Pacific, North America, Latin America and Africa.
In short, once you have created the XML payments format the majority of the hard work is done.
2. XML Payments are Supported by Most Banks
Okay, i have said MOST banks – not all banks support the XML payments format – but this is where you as a corporate can start to pick and choose which banks you want to do business with. The point is you no longer need to use bank specific formats for payments, and should look to move away from those horrid bank proprietary formats which nobody (in your organisation or at the bank) knows anything about.
In the old days it was simply too complicated to change payment formats and as a result you ended up ‘sticking’ with your existing banking provider. XML removes that technology ‘stickiness’ that banks previously had with their customers.
3. XML Payments Simplify Development and Support
I mentioned that XML payments can be used globally and by most banks – that gives you the opportunity to reduce the number of people (business and IT) developing, maintaining and supporting payment file formats in your organisation. You no longer need people to know the specific payment file format in Indonesia for example, you need a core team that understands XML payments and they should be able to support the payment formats globally. Since XML is a global standard, you can easily hire a consultant to make whatever XML changes you need in a relatively short amount of time. That ease of maintenance/development is not always available with old proprietary formats.
Some ERP systems are able to generate XML payment file formats ‘out of the box’. That doesnt mean you can use the XML payments format straight out of the box, it is highly likely that you will need to do some tweaking. Both to make sure the format adheres to your business requirements and meets your banks expectations – but its a whole lot better than developing something from scratch.
4. XML Payments Can Be Used For Most Payment Types
XML payments format can be used for the majority of payments that your organisation is currently making – especially the high volume payments. XML payments can be used to initiate:
- Most domestic supplier payments – ACH (Automated Clearing House) type payments
- Cross border, priority payments or wire payments
- Payroll payments
You need to understand from your receiving bank how they need you to populate the PAIN.001 XML format. For example in the SEPA zone, payroll payments need to indicate the SALA category purpose code.
5. XML Payments Will Save You a Few Quid
Let’s not beat around the bush, upfront you will have to invest significant time, effort and resources in implementing XML payments. But once done you start to reap the benefits:
- As you deploy new payment interfaces in another city or country, your development and testing times are reduced
- You no longer need lots of people to support different payment interfaces
- Depending on the channel that you use – for example SWIFT FIN versus SWIFT FileAct – you can reduce your SWIFT charges by processing more of your payments through the cheaper SWIFT FileAct channel
- You’re no longer thinking about a brand new interface each time, if you use XML payments it should be a case of modifying an existing template
6. XML Payments Enables Payment Processing Efficiencies
With XML you can start to think how to improve the way in which you process payments at your organisation. XML payments will typically require you to indicate bank information using the BIC and IBAN code – of course, in Europe the IBAN is mandatory, but for the purposes of this post I’m thinking globally… This starts to standardise the:
- Information you need to collect in order to make payments
- Way in which you process payments
- XML payment file generated by your ERP system
- Delivery of that XML payment to your banking partners
All of a sudden the idea of a Payment Factory starts to sound a bit more feasible.
7. XML Payments Can Be Delivered Across Multiple Delivery Channels
XML payments can be sent to the bank or your payment processing provider through a variety of channels
- File upload into a internet banking system
- FTP or secure-FTP (SFTP)
- Host to host channel
- SWIFT FileAct
- EBICS
- Multi-banking file upload
You need to work with your bank to figure out which is the best delivery channel for your organisation.
8. XML Payments Enable Enriched Remittance Information to be Sent to Your Supplier
Contain your excitement….. !! The good news is that through the Structured Remittance Tag and the Unstructured Remittance Tag in the XML Payments format you can send a lot more remittance information than previously to your suppliers. This is great, eh? Now your suppliers can see which invoices you’re paying them and it saves them calling your accounts payable department with queries and all of the associated time and effort that involves. Well, its not quite there yet…..
Okay, now the bad news – while the XML payments format can handle additional remittance information, the receiving clearing system in many cases cannot. It’s going to take time for the local clearing systems to catch up and be able to pass on the remittance information to the recipient suppliers. Some banks and payment service providers have bespoke solutions that case pass this remittance information to your suppliers – talk to your payment providers for more information.
9. XML Payments Give you the Ability to Control How Your Bank Processes and Reports Your Payments
I have mentioned already that the payment file can be used to process a variety of payment types. This is enabled by indicating the appropriate values in the XML payment file that is generated – for example:
- Indicating a Payment Method (PmtMtd) value of:
- CHK will trigger the generation of a Cheque (yuck!) payment
- TRF will initiate a regular (ACH) type payment
- Couple the above with a Code of URGP will indicate that it is a Urgent payment and will typically initiate a same day wire payment
- Similarly you can indicate to the bank how you want the bank to report the transactions in a given file on your bank statement – using the Batch Booking tag you can request a single consolidate entry or individual entries
The above are just a few examples of how you can control the way in which your payments are processed. You need to work with your bank to understand the logic they use. Overall, it is pretty standard stuff. You just don’t have that level of control and flexibility over an old-school payment file format.
10. The CGI Group Exists to Standardise & Simplify XML Payments
The CGI group at SWIFT is responsible for promoting XML payments and simplifying the implementation thereof. In short, the SWIFT CGI group is dedicated to making it easier for YOU to implement XML payments – the CGI group have indicated the standard version of XML payments (PAIN.001) to use along with country specific modifications. Most of the big banks support this, and are involved in the development of these standards.
CGI are trying to do all of the hardwork documenting the various in-country requirements so you don’t have to!
Pretty neat… eh?
Pingback: The Most Boring Article About EBICS You'll Ever Read
Pingback: Quick Summary: SWIFT On Distributed Ledger Technologies
This is all cool, ISO20022, XML and stuff, but how can I import my data for more than one payment to this XML with pain003 schema?