SWIFT Integration: Making Sense of Automation

SWIFT integration can broadly be described as automating a range of activities. They include transformation (from SWIFT to non-SWIFT format); alerting when certain events occur or expected events do not occur; emailing departments, customers and beneficiaries; data aggregation; using an incoming SWIFT message from one correspondent such as an MT103 to create an outgoing SWIFT message of the same type for another correspondent; monthly or daily reports to head office; and audit.

Not all integration needs to be automated and it is common to mix methods. The following guide will help financial professionals determine which integration problems are candidates for automation and what method or combination of methods work best.

Integration Problem Defined

An integration problem typically occurs when communication between a source and a target is either not fully automated or the automation is inefficient – too slow, too expensive or not meeting functional requirements. Typically the source or target is an application, and the other either an application or a human.

A solution to the integration problem consists of replacing the manual process with an automated process or upgrading the current automated process to a better one.

Benefits of Automation

Benefits of automation are well understood, but worth repeating:

• Opportunity for revenue growth: Automated processes scale more easily allowing you to increase volumes and revenues.
• Efficiency: Leaving more time to focus on activities that are more important to your core business.
• Reduced Risk: Fewer errors, reduced business losses and easier to demonstrate to audit.
• Scalability   

SWIFT integration offers many opportunities to realise these benefits quickly and cost-effectively.

Key Integration Issues

Integration issues arise from a mismatch between source and target, which can occur as follows: 

1. Structure: A call for data standardisation – Here, source and target have different structures although the data required by the target may be present in the source and translation is required to convert from one format to another. A common example is when the source is a FIN (or MT) message and the destination an XML (or MX) message.
2. Content: A call for data enrichment – In this case, data required by the target may require information not contained in the source. One example is when the source (the SWIFT application) contains only the bank identifier code (BIC) code but the destination (in this case, a human being) wants to see the name of the correspondent. Alternatively, the data translation from source to target may not be straightforward. An example is when the transaction type/identification code in a SWIFT MT940 end of day statement does not translate exactly to the type code in the US BAI2 file format
3. Process:A call for process efficiency – Here the processing flow between source and target differs (data and structure may or may not differ). One example is when the source system provides an end of day statement (e.g. SWIFT MT940) by account, whereas the target system requires the end of day statements by geographical region (i.e. grouping together all the accounts in a geographical region). While the format MT940 is the same in the source and target systems, the processing flow differs.
4. Adapter: A call for transparent communication – Here the technical interface between the source and target systems differ (e.g. the source uses web services and the target uses MQ. 

Common Integration Solutions

The most common integration solutions include:

• Manual: Leaving the process manual can be best when the alternative is expensive or difficult to implement.
• Custom Code: Writing custom code specifically designed to solve a single integration problem.
• Middleware: An application that handles some integration issues out of the box, but may require custom development to solve specific integration problems.
• Utilities or tools provided by the application: Applications usually come with tools that can be used to solve integration problems, such as the SWIFTAlliance Access (SAA) application.
• New application: An application that doesn’t integrate well can be replaced, or an application purchased, to replace a manual process.  

No organisation uses one of these methods exclusively. The most common practice is use a combination of methods to address multiple integration problems. A method that works best for one problem won’t necessarily do so for others. Also, sometimes multiple methods can be used to solve the same problem and the financial professional must choose which works best in the context of his/her organisation. The following section offers some real-life examples taken from customers.

Manual Solution – Payment Processing

Here an incoming MT103 payment goes through the following steps:

• A payment validation results in and error and the payment is returned.
• The payment is valid and goes through multiple processing steps in two different departments before being sent to an accounting application.

An important point is that the accounting application accepts the MT103 in the same format in which it was received, avoiding any structure or content mismatch. However there is a workflow with multiple user interface screens where users input additional information about each payment, creating a process mismatch between source and target.

Middleware Solutions

Middleware solutions usually follow a standard flow such as the one shown below.

Middleware solutions are good at solving adapter and structure issues, often providing out-of-the- box solutions such as a set of technical adapters covering file, MQ and web services to handle adapter issues as well as a set of message standards defining the structure of messages in the markets that middleware providers cater to. For example, any middleware vendor serious about SWIFT will have the standards of all SWIFT messages defined (including FIN MT, ISO 20022 XML also called MX and FileAct).

To resolve content and process issues outlined above, middleware vendors require you to develop custom code so it is important to understand the two cost elements to a middleware solution: a software licence and a services component to deliver custom integration.

Some vendors will already have built the custom code into their middleware solution and will have it available out-of-the-box. In this case, there is an added charge for each out-of-the-box solution purchased.

Middleware products are fairly powerful and can be used to solve various problems including various kinds of translations converting between the many different standards that exist. SWIFT itself has multiple standards such as MT and MX and translation may be required between them. As each domestic market has its own standard(s), translation may be needed between the domestic standard and SWIFT. Finally, even a single standard such as FIN is not implemented in the same way across institutions – middleware can help in translating such differences.

Utilities and Tools

This section focuses on Alliance Access (SAA) and Alliance Gateway (SAG) applications; SWIFT’s messaging and connectivity solutions. SWIFT greatly increased the number of command line tools available with SAA 7.0. A full list of command line tools and brief descriptions are given below:

1. Saa_monitor: Monitors various entities (message partners, queues) within SAA. While SAA is running smoothly, an entity may fail and this tool helps monitor the entities in an automated fashion.
2. Saa_manage: Automatically corrects any errors in the entities that saa monitor has detected.
3. Saa_query: This command can query any kind of information within SAA including messages and events. The SAA defines 1,035 events ranging from an invalid message format to an operator getting disabled. When used for messages, the information can be retrieved and stored in a data warehouse for subsequent query and reporting. When used for events, a sophisticated range of alerts can be generated, customised to deliver targeted alerts for specific events.
4. Sag_system: This command allows event information to be retrieved from the SAG event journal in a similar way to saa_query. SAG has 512 events covering for example a partial failure where FIN processing proceeds as normal but FileAct fails. SWIFTNet Link and the Hardware Security Module (certificate storage device) events are also promoted to the SAG event journal so that all events can be viewed together. 

Note that these are not typically considered ‘integration’ solutions. However consider the case of a targeted alert, which occurs when a message delivered from a back office application fails in SAA. Here the source is the SAA application, the target of the error an individual who has to look into and fix the error and a manual process is involved when looking into SAA to determine that an error occurred.

Consider another case of using saa_monitor to automatically detect errors and saa_manage to automatically fix them. Without the use of these tools, the source application is SAA and the target is an individual who has to detect and fix the errors. With the implementation of these tools, detection and correction has been automated and the individual is still kept informed of what the automated tools are doing (typically via emails) and will still be required to step in for cases where the automated tools are unable to correct errors detected.

Therefore these cases fit the broader definition of SWIFT integration. More important, solving them can help increase efficiencies, at low cost and rapid implementation.

Outsourcing Integration

An interesting idea that can help reduce costs (especially software licensing costs in the case of middleware) and shorten implementation times (since the outsourcer may already have the integration solution built in-house). The individual can decide only to outsource the integration and/or to outsource a specific integration problem.

The reduced cost and implementation time-frames and the ability to use this tactically for specific solutions make it an increasingly attractive proposition. In this, integration is following the general trend towards ‘cloud’.

The Business Case for Integration

Finally some thoughts on the treasurer can make a business case for integration.

1. Determine what you are doing manually around your SWIFT system: This may/may not be obvious so make a list. Don’t assume that integration will not be possible or not be cost effective.
2. Assess these problems in terms of: Time: How much efficiency can you gain?; Risks: Which can you reduce? (Errors, business losses, audit requirements); Opportunity for revenue growth: Automation helps scale your infrastructure, producing opportunities for revenue growth.
3. Develop a list and a ranking of integration opportunities.
4. Leverage potential integration resources. These being internal IT; application vendors; SWIFT provider; middleware provider; and other external resource.
5. What is the break-even point to justify integration and automation? Some individuals use 20 transactions per day as a rule of thumb, but the cost/risk/efficiency impact that will determine it.

Conclusion

Akshay’s experience in working with clients indicates many challenges related to integrating SWIFT messages; usually these can be resolved quickly and at little cost.

While various solutions are available for these challenges, organisations often use a mix of methods and specific solutions that best match the problem at hand.

Presenting real examples help determine what integration problems exist and the elements in a business case to justify further automation.