Don't Break the Bank With Live SWIFT Development and Testing

One of the major cost factors in integrating with 3^rd party tools and services in your application is the availability of the tool in your dev/test environment. Whether there is a cost to use the tool in pre-production or there is downtime for that 3^rd party causing an interruption to your schedule, both situations cost time and money in the application development cycle.

The answer to this is not to pull back from 3^rd party integrations, it's to leap forward and eliminate the constraint to your dev/test cycle.

In the banking world, the SWIFT messaging protocol and network infrastructure is an almost mandatory integration for international interbank messages. The SWIFT standard provides a secure and reliable transfer of messages containing financial transactions between banks and other financial institutions. If you're transferring funds across exchange rates or even dealing with an intermediary — SWIFT is the most secure way to transact.

As with most 3^rd party live services, the live SWIFT service comes at a cost; one that banks are willing to accept when transacting real business as they can charge back the fee to the end users. However, when these companies are developing and testing their SWIFT integrated applications, the cost is not as easily justified. How can banks get around this pre-production nightmare and not "break the bank" before they get their application out to the masses?

Let's analyze our constraints and solutions.

Constraints

• Cost of access to the live service: Accessing a live service to test continuously is costly. Many simply wait until integration testing to see if a 3^rd party integration works causing defects to be found at the pricey end of the software development life-cycle.
• Testing with canned data: 3^rd party environments do not often enable testing with real data and instead provide a canned one or two transactions for testing purposes. Negative testing is limited to none and without true data, quality suffers. Defects simply spill to production.
• Non-human readable transactions: Swift messages are complex and not human readable. Spot checks by manual or user acceptance testers can be difficult with no ability to completely match transactions with their expected results. Without proper validation of messages, errors are likely to occur.
• Changing Standards: There are several SWIFT standards (MX, SEPA, MT) that change quarterly causing constant updates to live systems. This adds complexity to the validation of messages and ensuring any tests being performed are updated with the latest data available.

Solutions: Service Virtualization and Test Automation

We should not fear the 3^rd party integration! With a combination of virtual services and automated tests with proper SWIFT assertions, financial institutions can remove this live service constraint from their development and test environments, thus increasing quality and reducing cost and time to delivery of their applications.