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.
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.
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.
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.
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?
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!
