CGI and the Path to Coopetition

For years, dealing with different domestic and international payment and account statement formats was a primary challenge within the domain of corporate payments. In this format-centric era, the concept of the Payment Factory/Payment Hub was created and many large corporates embarked on implementations that centralised the payments initiation process.  But these implementations remained focused on supporting the large array of payment formats that were supported by banks at that time.  One of the perceived benefits of a centralised payment factory implementation was that it facilitated a rapid global rollout to all parts of the business.  However, the differing formats in each country meant that each rollout phase typically took longer than desired.

In response, SWIFT launched SCORE in 2006 to accomplish two things: it opened the SWIFT network to corporates in a more efficient way and, in 2008, it introduced the concept of a multi-bank payment format implementation guideline based on the ISO 20022 XML payment initiation messages.  This became known as the SCORE Implementation Guideline and was adopted by some pioneering corporates who saw it as a way to standardise on a single format framework (replacing domestic formats) to enable faster rollouts. 

The larger cash management banks recognised the benefits of the SCORE implementation guideline and ISO 20022.  Yet, they saw the limitations of this guideline and the problems encountered during implementation and so decided to work on a new guideline that would seek to address the problems of SCORE whilst extending the scope of what would be covered.  This led to the creation of the Common Global Implementation Initiative (CGI).

Put simply, CGI is a suite of ISO 20022 XML Payment Initiation Messages that can be used for many different payment types, replacing the need for corporates to support bespoke, domestic formats.  As such, CGI helps to move payments away from being a technical formats challenge to one of data, i.e. what data do I need from my back office for a given payment type?                                                                                                                    

To understand CGI it makes sense to start by looking at ISO 20022. Released in 2004, ISO 20022 is a common methodology for defining electronic financial messages and a common business repository / model from which those messages are produced.  A key goal of the ISO 20022 initiative was to have the same message for all types of credit transfers.  It offered the corporate the potential to move away from having to construct the same basic payment information differently for different payment instruments. 

If this is all true, why the need for an implementation guideline like CGI on top of ISO 20022?  

Well firstly, the ISO 20022 XML message is huge.  It has hundreds of fields, many of which are rarely used. CGI includes a subset of those fields in an attempt to make the messages more manageable.  Secondly, where message fields need to carry a code, these codes are defined as part of CGI.  Previously this was not the case and it led to a proliferation of non-standard codes across the banks.  In addition, certain fields within CGI are designated for bi-lateral agreements like SEPA.  There is agreement between the banks on what is ‘standard’ and what is left for value-added services. 

This is classic “coopetition” – cooperate on areas where it makes no sense to be different and compete in other areas with value-added services that may require additional date.  Lastly, to ease the burden on the corporate, the receiving bank distinguishes between data it does and doesn’t need to see.  As such the corporate can supply the superset.

Could CGI become the implementation guideline for SEPA?

The common denominator of CGI and SEPA when discussing credit transfers for making payments is that they both use the same format – an ISO20022 payment initiation message. There are different rules about what fields need to be populated for a SEPA payment and for the different CGI payments.  But ultimately is a SEPA payment not just one of many different payment types that should be ? So, CGI have written to the European Payments Council (EPC) to ask whether in the corporate-to-bank space, the CGI guideline can be used as the SEPA guideline so that we just have one in the corporate-to-bank space called CGI.  Then, if you wanted to make a Euro payment using the CGI guideline then it would be SEPA -compliant by default. This makes much more sense to the corporate because, rather than having potentially to get a different version of the XML message and populate it separately for SEPA, CGI want to have it as the standard within that guideline so that it’s all encompassed and no longer a ‘special case’.