The answer to this is not to pull back from third-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 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 live third-party services, the live SWIFT service comes at a cost; one that banks are willing to accept when transacting real business as they can charge the fee back 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 in SWIFT development and not “break the bank” before they get their application out to the masses?

SWIFT Development: Constraints and Solutions

Cost of Access to the Live Service

• Constraint: Accessing a live service to test continuously is costly. Many simply wait until integration testing to see if a third-party integration works, causing defects to be found at the pricey end of the software development life-cycle.
• Solution: Banks can virtualize subsystems that are sending and/or receiving SWIFT messages. This completely eliminates the pre-production transaction cost and any fluctuation on the SWIFT live service.

Testing With Canned Data

• Constraint: Third-party environments do not often enable testing with real data and instead provide one or two canned transactions for testing purposes. Negative testing is limited to none and without true data, quality suffers. Defects simply spill to production.
• Solution: With a virtualized SWIFT service, data passed in and out of the system is not restricted by a third-party test environment. Test data can be captured with various tools and fed to systems during the pre-integration test phase, without restriction.

Non-Human Readable Transactions

• Constraint: 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.
• Solution: With service virtualization, SWIFT transactions can be “translated” into human-readable XML for easy troubleshooting of requests and responses. In addition, with the proper tools, syntax, and semantics of SWIFT messages can be validated, dates can be identified in the transactions, and stateful transactions can be captured and understood properly.

Changing Standards

• Constraint: 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.
• Solution: Automated tests can be set up for each version of the SWIFT standard and updated before the new standards go live.

Conclusion

We should not fear third-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 application delivery times.