Making ISO 20022 work for you: IT architecture

Yes is the short answer. 20022 absolutely opens opportunities.  Ever since the 2013 release when the model became consumable it is now possible for banks  to start using 20022 as a basis for their internal enterprise data and message models.

Two+ years on though, one might reasonsbly expect to hear of the occasional success story and some case studies.

One word of caution.  If one were to attempt to define a simple internal message model for a cash transaction it would likely contain an account number. Upon a search of the repository you would discover 29 different definitions of a CashAccount message component.  How can that be?  How is a bank to determine which (if any) of these is the best fit? 

Another example, there are 113 different definitions of CorporateActionOption.  This beggars belief, not least because there are only 13 coacs message definitions.

Could it be that this is somehow contributing to the slower than expected uptake of internal adoption of 20022?

Good points, well made, Steve

I believe that SWIFT Standards and the ISO 20022 RA are working to clean up old and unused or redundant logical message components at this very moment - This is a non-trivial task, constrained as they are by the very strong governance and change controls built into the ISO 20022 standard, and by the need to ensure that users of the standard are not impacted by such "technical optimisation" efforts. It appears to be working though, because I’m only seeing 67 CorporateActionOption and 26 CashAccount Message Components in the latest e-Repository (published October 5th) - There’s obviously still some way to go, but that’s already a big step in the right direction - the ongoing push towards industry harmonisation will greatly accelerate this work if it can help ISO to retire some of the very old messages.

When looking to define an internal model though, a unique strength of ISO 20022 among financial standards is that each of these logical Message Components is a view on a single Business Component in ISO 20022’s normalised conceptual model. It is a fact of life that there will always be many different logical and physical representations of information across hundreds of different financial business transactions, but at least in ISO 20022 these are all representations of a single globally standardised information concept.

To make this a bit more concrete based on your examples, the ISO 20022 Business Model defines the CashAccount concept only once – all business attributes of a CashAccount are also standardised once, and the CashAccount’s place in the hierarchy of accounts is formally specified. Its associations to other financial concepts (such as AccountOwner and AccountServicer, AccountContract, …) are also formally modelled at the conceptual level. The same is true for the single CorporateActionOption Business Component.

So, even if we are looking for a technical internal canonical messaging model, our search can be very powerfully guided by starting at the business model. Once we understand the big picture of the concept we are looking to model as a message, DDL, Web service, …, we can follow ISO 20022’s traces down from the Business Model to understand how the concept physically manifests in a specific business process, business transaction, and messaging flow. In this way, ISO 20022 even supports us to model independently of the physical syntax (for example, independent of whether your CashAccount information happens to be in an ISO 20022 XML syntax message, a FIX message, an MT message, a database record, …)

As you know though, the reality is not yet as simple as the theoretical story that I tell here, and I agree that that this is likely to be behind the dearth of public success stories. This is a great example of the kind of challenge that we’re looking to tackle in the Architects’ Forum mentioned above though – watch for your invitation coming soon Steve ;-)

Steve - I've been working alongside Jamie as part of the ISO 20022 Forum for Architects. I've opened up the model from the business components side as a first step in making sense from an EA perspective. This gives a great canonical model, dictionary/ontology and domains as an entry point before looking at the physical implementation (message).

This would be my starting point for a simple transaction.

Admittedly the eRepository does not have the MDR information included yet, this is apparently coming later in BPMN format (maybe we will get XPDL as the implementation format too).

One final comment - you do need the standard to hand to leverage and adapt the eRepository successfully, perhaps incorporating within an organisations architectural principles.