ISO 20022 and banking APIs

16 03 2017

I think there are a few perceptions of what ISO 20022 is, which are actually quite wrong, or unfortunately just focus on one area of 20022. In this post, I don’t want to go through ISO 20022 in great detail, rather give some background pointers on it, and to look at how ISO 20022 can be used in a banking API.

So first off, what is ISO 20022. Wikipedia has it as an ISO standard for electronic data interchange between financial organisations. Quite frankly this is very narrow of what 20022 actually is. I would better describe it as a framework for what best describes financial based product types, associated data, business processes and finally, the exchange of information – though not just between financial organisations. I prefer to think of ISO 20022 like this, though it is technically a data dictionary and business process definition list. 20022 has been around for some years, I think over a decade now, and all throughout that time, institutions have been contributing to the standard, growing it and making it more valuable to the community (in my opinion).


Though this isn’t a new standard, adoption has been slow. Here in the UK we have, at best got “interested parties”, though that interest continues is gathering more and more momentum. None of the UK payment schemes operate on ISO 20022, though this year has seen the big three (Faster Payments, Bacs and CHAPS) working on or publishing documents that “map” ISO 20022 message interfaces to their native scheme interfaces. In addition, I don’t know of any banks that operate ISO 20022 for messaging, let alone for definitions of products, data capture and business processes – exception being ClearBank. You may be wondering then why ISO 20022 is worth implementing? Well, there are a few big wins in implementing it, the first being you can standardise your entire financial organisations processes no matter the types of products you decide to create/model, the services you wish to provide and the banks/schemes you may wish to integrate with. That drastically reduces the amount of code duplication, it centralises shared processes reducing components that require testing, eases maintenance and all in all, makes life much easier for your business. ISO 20022 reduces RISK across all aspects of your business. In addition, 20022 is gathering momentum, it is simply a matter of time before ISO 20022 is enforced on institutions.

Now armed with this little bit of knowledge, let’s look at some of the key elements that make up ISO 20022.


Definition of financial products

Believe it or not, ISO 20022 describes what sort of financial products can be created. This is done at quite a high level, I prefer describing 20022 as a framework, as that’s really what it does, provides you with a framework in which to describe your financial product. For example, your current account, or savings account in ISO 20022 is considered to be a cash backed account product. (Refer to the ISO 20022 documentation for its formal name). 20022 describes other forms of products at that high level, remember it covers all types of financial organisations, p0roductgs and services, including things like shares and derivatives. However, let’s think of high street banking, think of all the flavours of banking type accounts you can have, they all fall back into that top level “cash account” product type.

In defining a product like this, ISO 20022 also provides information on associated data that should be attached to a product when a customer opens/has that type of account product. If you’re a FinTech, or challenger bank, then grasping this could in the long run save you lots of heartache, while at the same time help build out your account type specifications.


Account holder detail

Just as ISO 20022 helps define products, it also defines what data a financial organisation should be holding on account holders. Not always done in the most intuitive of ways, none the less, the standard does expect certain data to be held. Most of this is common sense, but there are the odd items in there that you may have overlooked, so from that point of view, ISO 20022 will help you validate what data you’re holding. Please note though, this isn’t definitive, use it as a framework, hold more data if you have a business case, and not all of it if you do not. Remember, data protection legislation, along with lots of other data considerations when it comes to holding account data.


Business processes

I think many forget or simply don’t know that ISO 20022 sets standards for very specific business processes. Keeping in mind, that 20022 handles ALL forms of financial organisations, there are lots of processes in there, however the two that really interest, I would say the majority of banks, credit unions, FinTechs, challengers etc are around Payment Initiation (known as PAIN) and Payment Clearing and Settlements (known as PACS).

ISO 20022 defines these processes. Now again, they are really to be used as a framework, but if you are a challenger bank, or a FinTech, it is well worth spending some time to familiarise yourself with these, they give you a definitive process that enforces you do the right things, such as consider your regulatory reporting requirements.


Message interfaces

This is the most commonly known feature/function of ISO 20022, the definition of financial information exchange. PAIN and PACS messages are fully defined, now I’m not always one for “standardisation”, as I often find it stifles creativity and innovation. However, when it is applied to something that is “fundamentally part of the fabric”, if you like, of shared interests then it works brilliantly and encourages innovation. Where would we be without HTML and the W3 standard? For me, financial transactions, their definition should be standardised, this will help stimulate creativity and ultimately financial service/product innovation.


Banking APIs

There is a lot being made of banking APIs, or the lack of. There are two big factors why we don’t have open banking APIs IMHO;

  1. Aging legacy banking systems
  2. Risk factors
  3. A standard approach

The first one is pretty obvious, but the second is the main challenge that really faces banks. That Risk is in two main areas, the first securing the API, and that can be challenging if you want to make it open, the second is in terms of who carries Risk of the payment. With PSD2, that Risk conversation needs a lot more thought. The third issue is a standard for the API or messaging.

ISO 20022 provides message interface definitions, and it really is the most obvious choice for banks to build APIs around. However, ISO 20022 doesn’t have a standard or process for securing message interfaces / message exchange channels. I personally think that is a good thing – lots of personal reasons why which I will not run into in this blog. ISO 20022 messaging is also an XML based interface definition, nothing wrong with that, but that can be heavy on network traffic. JSON is a much better choice for message interchanges, especially when we look towards RESTful based APIs. So what is the answer….

Banking APIs can be delivered via REST, they can be secured using Public/Private Keys and tokenisation, all technologies and methodologies that have proven track records for security. So the only challenge is the XML message definition being wrapped up in a more appropriate format, JSON. Well that’s not a challenge, simply serialise XML payloads as a string.

So while ISO 20022 doesn’t define APIs it provides us with a message interface standard, which can be used as an API payload. In the open banking API debate, the answers have been sitting there for quite sometime….


More on ISO 20022

There is lots of information on ISO 20022 at which is obviously a great source. There are digital libraries (java classes) though I would recommend the written documentation. Obviously a standard shouldn’t tie you to a technology, like Java, however the XML schema definitions have a little left to be desired, so when importing using other tools than those used to create the digital libraries you end up with lots of class duplication. Frustrating I know, but a skilled dev can get around that by writing some additional code. It’s something that needs addressing and probably will do over a longer period of time.

There are also lots of guides on the standard, I’ve even seen a “dummies guider to ISO 20022”, you obviously know its something worth learning if there is a dummies guide….

First new UK clearing bank in 250 years

6 03 2017

I’m hoping that if you are reading this blog, you are already aware of ClearBank ( and have probably read some articles on-line. To be honest, it’s been a lot of hard work and it was great to finally watch Nick Ogden, ClearBank Chairman, up on stage announcing the official launch of ClearBank on Tuesday.

The title of this blog says it all in some ways. In recent years, we have seen a lot of challenger banks being formed in the UK, partly due to the increase demand for competition from us, the consumer, and partly because of the hard work put in by the regulators to encourage the creation of banks. However, it’s been 250+ years since a new Clearing bank was formed. 250 years! When you think of all the changes this planet has seen in those 250 years, changes such as the first train journey in 1804, the invention of the bicycle in 1816, how about the wright brothers first flight in 1903, and then two of my favourites, 1959, the first man in space and what about the first commercial use of the Internet in 1995, it’s almost unbelievable that there hasn’t been a new clearing bank in that time.

In the UK, until the launch of ClearBank, the UK had just 4 fully fledged Clearing Banks. Back in the 60s, that number was at 16, but due to strategic takeovers, market consolidation, the UK has found itself with just 4, until now, 4 has become 5.


What’s the difference?

You may be thinking what’s the difference between a challenger bank and ClearBank, or a clearing bank in general? Well its quite simple, banks that aren’t clearing banks rely on one of the clearing banks to provide them with some level of clearing services/accessibility to the UK payment networks. That’s every bank you can think of that operates here in the UK with the exception of the big 4, Barclays, HSBC, Lloyds and RBS. That means every bank and FinTech relies on those banks, and therefore those banks IT infrastructure, those banks integration services, operational processes oh and the fact that they are ultimately competitors.

ClearBank is utterly different. The focus is on providing access to clearing services, access to UK payments networks and core banking services to other banks, regulated organisations and FinTechs. The bank isn’t aimed at the consumer banking space, so ClearBank isn’t competing with its customers for customer accounts. The banks entire infrastructure and services have been purpose built, built now on todays technology ready for customers to utilise. As a FinTech, bank or other regulated business, you can finally connect to clearing services and the UK payments network through technology that is designed with this century in mind, via RESTful based services, through a proper SOA! This means ClearBank will be helping FinTechs innovate. As a previous FinTech entrepreneur myself, I know all too well just how restrictive legacy IT from your bank can be, how frustrating it is to your ability to innovate. It’s so frustrating to have an idea, a vision, but to realise that someone else’s technology stops you from being able to deliver.


The impact?

ClearBank will help and encourage market competition, it makes it easier for institutions to access clearing services, it makes it easier and drastically reduces the costs involved for institutions to offer their own current account services, and it makes it drastically easier for FinTechs to innovate and build on banking services that are fit for the 21st century.

The impact is simply massive on the financial services industry, and massive to how banking will be delivered in the UK over the next few years.


Find out more….

If you haven’t done a basic search for ClearBank in your news feeds, Bing, Google or even on Twitter then do so. There are hundreds of articles now available on-line for you to read at your leisure. However, you can learn pretty much everything you need to know from the ClearBank website, and this short video….Enjoy…

User features to help ECM adoption

20 05 2010

In the past couple of weeks, this has been playing on my mind quite a bit. As a vendor, what can ECM software provide to make life far easier for users to really adopt ECM and ensure as much content as possible makes its way into the repository? Now, I don’t want this to turn into some woolly post with lots of comments that really don’t mean much, and I want to steer clear of those generic sentances that ECM so often throws up, the ones along the lines of “interface simpler and cleaner yet facilitates greater functionality and efficiency”…great, what does that actually mean…

This post is more of a conversation, than your typical blog, and I want to get people involved here to really put real life ideas forward. Some of them may seem very “out there” but thinking outside of the box is really the only kind of thinking that makes radical changes. So speak up….

I have thought of some things to get the ball rolling, I don’t want to put too much into the post itself as often that seems to get people just agreeing, or disagreeing, as I said, I want people to put forward their own thoughts and ideas…

Out of the box solutions

These are tough, and are required to provide accessibility for SMEs to ECM and to also allow larger enterprises to roll out department by department with an initially low investment. However, out of the box solutions and applications often are “clunky”, so a couple of things spring to mind here….

  1. Let’s let the user configure the “look” of the application. As soon as a user can “tailor” something, they have a little more interest in it. Just look what we all do to our own Windows backgrounds and icons for example
  2. Increase application usability. Be this using things such as drag and drop or something else. I like drag and drop, but I also like context menus and intelligence in the application shown, knowing what sort of content I am working with and only providing me with valid “drop zones” or context menu options…
  3. Mix desktop and the web. I am a strong believer in using the desktop to deliver greater user experiences but we need the flexibility of the web.
  4. Ease of uploading files. Need to be able to make this quick and easy, and not have to ask a user to do a hell of a lot of indexing….
  5. Custom searching. Let’s make it easy for users to create search templates, and save them.

I am sure there are other points that should be raised for out of the box applications, but these are just some starting points. So comment away…..

Application integration

This is always a big thing for me, the more applications that ECM can integrate with, the easier it is to adopt and more of the benefits of ECM are realised within the organisation. So what are we thinking here:

  1. Easy to use ECM tools within typical office applications, such as MS Office
  2. Background integration. By this I mean, automatically reading content out of an application and placing it within the repository.
  3. Tie together key index fields with other systems key fields. Think CRM and overlap the customer details (maybe their account number) with the ECM based content. This makes integration far easier, while also allowing the two systems to work independently but with the same information
  4. XML Web Service availability so that any other application can pull in / integrate with the ECM platform. Web services are a great way of doing this, and really should become the standard for which all ECM APIs are written with….

Ok, I will stop here now. There are so many areas to look at here, and I would love to hear what people think, be you a designer, a developer, a business decision maker, an end user, a BA etc etc.

I look forward to the conversation…

A little puppy dog…

8 09 2009

Ok this isn’t really related to my normal posts, which are usually work(ish) related. So today, I thought I would share with everyone that a new edition joined the household this weekend. His name is Diesel and he is only 5 weeks. I know, only 5 weeks, didn’t expect him to be here until he was at least 8 weeks, but the vet said was all ok so here he is…

He is a little black lab and is a ball of energy, fun and some destructive power, well for about an hour then he needs another hour + sleep…Which is fine with me, as I am still nursing a horrid feeling body after my Stag weekend….

So far, nothing out of the ordinary to report. The cats don’t seem to like him (we have two cats aged 3), but they haven’t run off or anything as yet. So that’s a good thing. He is, sort of, managing to do his business on the allotted news paper so another positive….I spent a little time online last night reading up on house training your little puppy, and his dedicated room is now full of his toys, his bed and most important of all, 5 tabloid news papers spread out everywhere…

He has however managed to find his little voice, think he found it this morning at around 6:30, treating us to a great rendition of a howling puppy, which this morning was a novelty but if it’s happening every day, one that will ware off very quickly.

Anyway, I must now return to the real working world and get a move on with a desk full of work…I will keep you all posted from time to time on the domestic dog situation as things progress…