During the SEPA implementation, there was a common objective to develop and deliver the required SEPA XML payments format. Having gone through the PAIN (see what I did there?!) many corporates are now looking to utilise the ISO20022 format for other (non-European) payment processes that they may be running. After all it makes sense to get rid of as many bank proprietary / country specific formats and utilise wherever possible a common and ‘bank agnostic’ XML format. The idea being that the SEPA XML payments format will fulfil 90ish% of the format requirements and with a bit of tweaking here and there the corporate would be able to utilise the XML payments format universally. It makes complete sense, and the purpose of this post is to share 7 of the most common XML payments errors that I have come across…
Please note, these are not specifically SEPA XML errors but more general XML payments errors that you may encounter outside of the SEPA region. Typically these XML payment errors will result in your payments failing.
XML Payments Error 1 – Ensure you’re using the right PAIN.001 version…
While many banks and corporates are now adopting the CGI (Common Global Implementation) PAIN.001 version 3 message. Some banks, countries or corporates may still be using an older version of the PAIN format though, make sure you know what you and your bank can support and enhance the message accordingly…
XML Payments Error 2 – Use the right Payment Type Code…
Each country uses a slightly different Instruction Priority code <InstrPrty> or Clearing Channel <ClrChanl> code within the Payment Type Information <PmtTpInf> value to identify the type of payment being made. For example, RTGS for Real Time Gross Settlement is a widely used code for urgent payments. But local ACH (automated clearing house) payments in a country will have different Payment Type codes to help indicate through which clearing system and priority you would like the payments to be processed. Make sure you know the specific in country Payment Type code requirement and specify this code in the XML format that you’re generating…
XML Payments Error 3 – Get your lengths right…
While the ISO20022 XML specifications state that the beneficiary names and address lines can be 70 characters, sometimes in-country or bank specifications will override the stated ISO requirements. A common deviation is where the beneficiary name has an in-country maximum number of characters that is less than 70 characters. In this case if the indicated name in the XML payments format is longer than the required number of characters the bank will reject the sent payment.
Ensure you know the country clearing system and bank requirements and adhere with them.
XML Payments Error 4 – Structured or Unstructured Remittance Information, never both…
Some clearing systems / banks will not process remittance information you send in the Structured <Strd> tag, and will request that you send the Remittance Information (that will be subsequently passed to the supplier) in the Unstructured <Ustrd> tag. Typically where this is the case, it will be a requirement for you to state the Unstructured tag with a maximum of 4 lines of 35 characters (4 lines * 35 characters) – but again check this, the bank may have a quirky requirement for you to indicate something other than the typical 4 lines of 35 characters (4 lines *35 characters).
XML Payments Error 5 – Indicate the Correct Currency Code Decimal Places…
Some currency codes require zero decimal places – you need to ensure that you reflect the amount <Amt> accordingly in the XML payments file that you generate. In some instances your bank may be able to interpret and round up or round down the amount for you – but you may in turn end up with slight payment instruction amount <InstdAmt Ccy> discrepancies. Test and ensure you have the correct set up in place to handle the required decimal places…
XML Payments Error 6 – Specify the Country Codes…
Within the Debtor Agent <DbtrAgt> and Creditor Agent <CdtrAgt> tags you indicate the respective payer/payee bank details. Some banks require that you specify the Country Code <Ctry> in this block too so that the appropriate Clearing System Member Id <ClrSysMmbId> value can be determined where you have prefixed the Clearing System Member Id value with XXXXX. If you fail to indicate the country code, the bank may not be able to determine which clearing system to submit the payments to.
XML Payments Error 7 – Miscellaneous…
So here I wanted to highlight some of the SEPA related items that I have covered already in previous posts – most notably:
- Ensure that you know how your salary / payroll payments will be processed, and indicate any required values accordingly. For example with SEPA, you need to state SALA n the Category Purpose Code – check out the post the SALA in SEPA Salary Payments for further information
- Understand how you would like your payments to be processed and reported – in bulk or as individual payments – and indicate the Batch Booking tag accordingly…
- Make sure you only indicate Supported Characters in the XML message
- Do not indicate empty tags – check out the post SEPA XML in a Nutshell for further details…
XML Payment Errors – What next?
The goal is straight through processing…. With that in mind the ultimate advice is to always make sure you get a file format specification from your bank before you even start thinking about or developing a country specific XML format. Next, manually create the target format and share it with your bank. If your bank can validate the manually created file then you have something very specific and real, alongside the specification, to hand to your IT folks. Well those are my 7 most common XML payments errors, do these sound familiar to you, what else have you come across…?
Pingback: 10 Reasons Why You Need SWIFT Connectivity
Reading the seven failures above does not mark SEPARATE as a failure to me. It marks implementation team failure to me. As anyone who has been involved in an ICD (Interface Control Document) right back to EDI or even further to, say, multiprogramming, the failure is an elephant trap. Merely specifying a “standard” is not a quick way to ensure that all parties to the standard mean the same thing for the use OR SYNTAX of a field. Despite this illusion, many will dread the intense resource that needs to be deployed for each and every party subscribing to the standard’s use. Further, the use of an ICD is defined as removing the knowledge of or subscription to the method of processing by either or all parties to the interface. Indeed, that is one of all edged benefits.