Is SWIFT Corporate Access a Catalyst for Standardisation?
The lobby for standardisation of corporate-to-bank connectivity is not a new phenomenon and remains an ongoing focus for the industry. Corporates with multiple banking relationships still encounter day-to-day challenges in terms of barriers to straight-through processing (STP) and the cost of supporting multiple connections and formats. And this is not just a challenge for the outgoing message; there is also the problem of auto-reconciling incoming statements from multiple banks with different formats as well as the added complexity of data inconsistencies between banks.
The good news is momentum towards standardisation has been increasing year on year, and there are a number of driving forces behind this, such as centralisation, the growth of payment factories and the work of the standards body, TWIST. The take-up of SWIFT corporate access is also a significant catalyst for standardisation and has substantially accelerated progress in this area.
In 2002, SWIFT opened its network to corporates for the first time when it introduced the MA-CUG (member administered-closed user group) model, which improved standardisation by enabling corporates to access the network to deliver various payment instruction types to their banks using the SWIFT protocol, security and formatting.
In Q3 2006, there were 170 corporates on SWIFT and the number is growing. The method of on-boarding corporates to SWIFT through MA-CUGs has recently been improved with the introduction of the SCORE (Standardised Corporate Environment) model and banks are currently working with leading corporates to pilot the new model. It is anticipated that SCORE will encourage further corporate take-up and, therefore, be an important factor in helping to improve standardisation in bank-to-corporate connectivity.
The next section discusses SWIFT corporate access and standardisation of bank-to-corporate connectivity in greater detail.
Bank-to-corporate connectivity can be divided into four categories and each requires standardisation:
SWIFT connectivity, as well as information hub models, provides a single data ‘pipe’ rather than individual connections to each bank. This improves cost efficiency for corporates as it is estimated that each communication channel can cost €20,000 in terms of overall maintenance and support. Once connectivity is achieved via a hub or SWIFT that pipe can be re-used for all banks.
Before 2002, there were a number of standard message formats available, such as EDIFACT, SAP IDOC and ANSI, but it is often argued that more than one standard is not really a standard.
On the SWIFT network, corporates send FIN messages for high-value urgent payments and the standardisation of formats for these types of messages is available. As a result, should a corporate wish to re-route transactions to a different bank there is no need to change the format and this gives corporates greater agility with the movement of their high-value payments.
The same is not true for low-value payments, which in the case of SWIFT can be bundled into a single file via the FileAct protocol. There are currently no mandatory file formats for low value payments and each bank typically has its own format requirements. However, there is progress toward standardisation with the ISO20022-compliant XML standard increasingly being adopted as a standard for low-value payment file traffic. Since the recent publication of the ISO20022 standard banks, such as Citigroup, have been working aggressively with the more innovative corporates to accept this first truly global format
Today, authenticating the identity of the sender of a transaction has to be performed with each bank individually. Banks with industrial-strength security will each issue their own version of a ‘smart card’ that generates a dynamic password. Corporates need one of these smart cards for each banking relationship, which is not the ideal situation for standardisation or interoperability.
With corporate access to SWIFT, there is the additional challenge of how to identify the sender of a SWIFT message (FIN or FILEACT). Although the BIC code identifies the sender, the code identifies the corporate that sent the message but not the identity of the authorized individual. Forward-thinking banks are now working on this next challenge: how to improve standardisation around the identity of the sender.
At SIBOS this year, a proof of concept was announced that uses digital signatures for payments via the SWIFTNet FileAct service, using a Citigroup-issued, IdenTrust compliant digital identity as the means to create a second signature in addition to SWIFT’s file-level signature.
With the help of French company, Danone, and its cash management payment’s application provider Datalog, the authorized Danone individual digitally signed a batch of payments that was then wrapped in a file using FileAct protocol and sent via SWIFTNet to Citigroup for processing.
To demonstrate global bank interoperability, BNP Paribas also participated in this proof of concept as a relying bank. Danone sent a second signed payments file via FileAct using the same certificate. BNP was then able to validate and rely on the personal digital certificate received within the payment instruction.
This is an important working example of both interoperability between banks and the ability to link authorized individuals to the transactions they initiate on behalf of their organizations using FileAct. A key factor in this scenario is the use of banks as ‘trusted third parties’ that use bank grade controls and apply know your customer (KYC) rules around issuance of digital identities as well as banking system acceptance and liability for misuse. In addition, the identities are subject to auditable, regulated and legally enforceable rules.
Corporates are beginning to include this type of functionality and level of standardisation in their RFPs. The challenge is for all banks to be engaged in this initiative and therefore improve interoperability of the digital certificates.
Standardisation of the data has always been a challenge, and will probably be the last of the standards to be addressed. There is often inconsistency from bank to bank about what data is required within each field of a message. In order for corporates to benefit further from STP this issue must be resolved.
Progress on standardisation has no doubt been aided by increased collaboration within the industry by a number of initiatives, including corporate access to SWIFT. For instance, in 2005 and 2006, the banks with co-ordination from SWIFT, were working together in what was agreed to be a collaborative space that would benefit the industry as a whole. The outcome was the movement to use XML as the standard for low-value payment message formats.
All corporates – whether they choose to join SWIFT or not – can now benefit from the advantages of the standardisation of formats using XML. With banks now focusing on digital certificates to resolve issues around the identity of the sender, there is no doubt that the industry is taking great strides forward in the standardisation of bank-to-corporate connectivity.