In every project, there is a need at one point to develop an interface with a counterparty (often headquarters). And in many cases, the maintenance of this local interface is a nightmare: many incidents, many bugs, every project cost is increased… The main reason for the trouble is because it’s a ‘local’ interface; hence, no one from the implementing team is aware of its standard, and often it is not well-documented or misunderstood. There are a couple of tricks to make it less likely a nightmare for your headquarters / IT team:
Don’t load directly into your core banking transactions table
Keep it dynamic, don’t hardcode
Always think about reconciliation
Make identification easy in your transactional/accounting table
Consolidate stored details wisely
Don’t load directly into your core banking transactions table
This is a crucial step. Regardless of the layout you want to integrate or send, avoid inserting data directly into the transaction table of your core system. Instead, employ a temporary application to load the data initially. In this application, include a field labeled “status” with values like “Sent,” “Loaded,” “Error,” and “To be processed.”
The benefits of this approach are significant. By ensuring 100% of the data is sent or loaded with distinct statuses, reconciliation becomes more straightforward. Local interfaces often have their unique rules that might not align with your core banking application. Without a temporary application, you risk loading 99% of the file successfully but encountering errors with the remaining 1%. Tracking which transactions did not go through becomes challenging. The local temporary application, being rule-free, allows IT to guarantee a 100% load and track errors seamlessly when transitioning from this application to the transactional one.
Keep it dynamic, don’t hardcode:
When you have your temporary local application, map it to a flat file or the transaction application dynamically, not through hardcoded rules. This makes it easy to make changes, get input from the business, and enhance the process without needing extensive development and change management.
Always think about reconciliation:
Design your local interface with reconciliation in mind. If you’ve followed the first point, reconciliation becomes easier at 2 or 3 levels, making it simpler to identify any differences. Avoid loading flat files directly into your transactional or accounting table to prevent nightmares during the reconciliation process.
Make identification easy in your transactional/accounting table:
Instead of using generic codes, use specific codes linked to the local interface. This makes it easier to track and identify transactions.
Link everything together:
Ensure there’s a clear link between the files sent or received by your counterparty and your core banking system. All references to core banking, accounting, and counterparty should be effortlessly linked for easy extraction.
Consolidate stored details wisely:
If you need to consolidate large volumes of data, store all details in a local application and link the ID of this application to your consolidated line.
Make the headquarters responsible for costs:
If there’s no business benefit from a local interface, push for the headquarters to cover the maintenance and development costs. Local IT often can’t handle these expenses on their own.
Don’t be afraid to say no:
Developing and maintaining a local interface can be costly and impact all future enhancement. If the headquarters or counterparty isn’t willing to contribute, at least partially, consider saying no. The best local interface is the one that is not developed.