Implementing a global XML payment solution requires careful planning and consideration. Asking the right questions upfront will reduce surprises during your TMS implementation, as well as govern how the solution will be supported and enhanced in the future. Here are our top five questions to ask your banking partner in order to plan a better global payment implementation:
What version of payments initiation files are your partners able to support?
When implementing with multiple banking partners it is important to find out if all partners will be using the same IS020022 XML version; different XML versions will have slightly different structures based on the ISO standard. This is an important baseline structure to establish. If some partners are on older versions of XML, extra time will be needed either for your bank to upgrade to a newer version or for you to build different versions of the XML for the different banks.
It is important to understand the distinction of the standard itself versus the implementation of that standard. ISO20022 XML is a standard. This does not mean the layout is identical across all banks for all payment instruments. There is natural variability which is permitted as part of the standard. Let’s take a few practical examples where the layout may vary to explain further:
Example 1: You make ACH payments to a bank in the United States and use the CCD remittance format (as opposed to CTX, PPD, etc.). There will be a placeholder in your file to tell your banking partner the remittance type for ACH is CCD as well as provide the remittance structure.
Example 2: You make boleto payments in Brazil, and must include the boleto number for the payment.
Example 3: You make SEPA payments in Europe, and need to add an indicator for an urgent payment in order to ensure it is settled the same day.
In all three examples, the payments have information unique to their payment type. The power of using the standard is that it has places for different types of information to be sent. Consider the standard will likely help you accomplish 80% consistency across your banking partners for critical fields that are sent for all payments. The remaining 20% is the natural variability that occurs due to different types of payment instruments and local clearing system requirements. It is the 20% of the project that will take the most time during your implementation.
What information is available in payment confirmations and at which points in the payments process can you receive confirmations?
Your payment implementation should be designed as an end to end process, not simply a file transmission for payments. Ask your partner at what points in the process they are able to provide confirmations and at what level of detail. Will you know when the file is received, processed, finally settled, etc.? Will your TMS system support having this information at different stages of the process? As you design your TMS processes for receiving and processing confirmations, understanding which statuses you will receive at various stages of payment processing is critical to ensuring a consistent process.
How will your banking partner manage their portion of the project?
It is critical to understand what level of support you will have throughout the implementation. Who will be involved from your partner company; and how will they ensure problems are resolved? Ensuring the right participants are available from your partner will minimise project frustration and lost time. It is inevitable that there will be questions or unanticipated challenges. Don’t land in the helpless situation of having problems during the project without having the appropriate contacts from the bank to resolve those problems. Ask upfront to ensure you understand the commitment level and implementation process from your banking partner.
If you are typically using an automated interface to transfer your files, how will you manage in a disaster recovery scenario? Will you be able to upload a file straight out of your TMS onto the bank platform?
Understanding your choices in a disaster recovery scenario is an important consideration in part of any payments project. Consider the scenario from the perspective of the payment initiator as well as the payment processor. Your banking partner may have high availability with limited windows of downtime. Consider what will happen if your connectivity solution to your banking partner becomes unavailable? Will you manually move files to the bank, or simply wait until the connectivity is available again? How would you manage urgent payments if your connectivity is down?
How will you manage upgrades to your XML version?
Each bank manages upgrades to their system through their own internal processes. It is important to understand how those upgrades are managed. For example: an XML version is going to be upgraded, will it be managed centrally, or by each individual country operations?
Doing your due diligence and asking the preceding five questions when implementing a global XML payment solution will benefit all parties. This does require careful planning and consideration but doing so will reduce surprises and allow you to better govern your TMS implementation. Good luck!
Amber Christian is the founder of Ace LLC. She has worked on SAP solutions for over 13 years, with the last seven years as a consultant. She has implemented Accounts Receivables, Accounts Payable, Treasury and Cash management solutions for North America, South America, Europe, and Asia in industries such as chemical, transportation, professional services, mining, and manufacturing. She is a frequent blogger and conference presenter on a variety of SAP finance and treasury topics.
