Building a bank…

Building a business is one hell of a challenge, so when Nick Ogden (yes, the founder of WorldPay) said to me that he wanted to build a bank, I was a little apprehensive. But before I could really respond, Nick explained that he didn’t just want to build a bank, he wanted to build the UK’s first Clearing Bank in 250+ years!!!!! I think most people would be intimidated, however, we felt that this was one of those rare opportunities that you get to re-imagine how an entire suite of services could be delivered. Back in 2015, this was the birth of Banking-as-a-Service (BaaS). 

TYou see, Banking-as-a-Service (BaaS) is a technology play, it’s middleware, its banking deconstructed and delivered in granular, individual services. Plug them together, build our your capabilities and you can start to deliver banking outcomes for your customers. But Banking-as-a-Service, BaaS, is more than just technology, it’s leveraging all aspects of banking, including your balance sheet and more….

Banking-as-a-Service I feel really was born in that room with Nick Ogden back in 2015. This really was the start of our journey, the journey of building out ClearBank. Not only have we built the first Clearing Bank in 250 years, it’s the first Clearing Bank ever to join the UK’s main payment schemes all at once, the first ever to build out its own technology and the first ever to be built completely with Cloud technologies, and the first true provider of Banking-as-a-Service. A quite a few firsts there….

At the UK’s Azure User Group, I talked about some of our journey, some of the challenges and actually, how would I build a bank today…You can view the video here….

 

ISO 20022 and banking APIs

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 http://iso20022.org 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….

Tech looking for a business problem to solve

There are some wonderful new technologies coming to the market at an alarming pace it seems, some technology really helps a particular market, perhaps speeding up processes, changing our experiences, even having quite an impact on our lives. Then we have numerous technology that seems to be made, simply because it can be.

Just in 2014 alone (already and it’s the start of February) I’ve been exposed to a number of new technologies that are technically impressive, but they don’t have a problem to solve. They don’t have a real way of impacting our lives as consumers, or as businesses. Technology for technology sake is a phrase that I find myself uttering quite often, and none more so than when I look at the world of mobile and of-course, mobile payments.

 

My friend, NFC

NFC is a technology that has been around for years now. I remember it in an early Nokia phone (dumb phone not a smartphone) and it’s never really delivered anything in terms of impact on my life. I will be honest, most phones I have owned have supported NFC, and yet I have never used the technology for anything more than showing that it works.

Don’t get me wrong, there are some wonderful applications of NFC, but it’s a technology that doesn’t really solve any real issue, no matter what it is used for. Sure, it’s great for sharing data quickly, perhaps triggering music from my phone to play on a set of speakers when I rest my phone on them, great, but has that changed much compared to playing via Bluetooth? No, not really, if anything, NFC is more limiting than my Bluetooth pairing of speakers to my phone.

When we look at mobile payments, I still can’t shake the feeling that it’s a great technology trying to fit into this space, even though it doesn’t quite fit.

At the end of the day, NFC feels like a great technology, but for the sake of technology. NFC doesn’t change the game.

 

Bluetooth beacons

The latest mobile and mobile payment tech to raise its head is beacons. Apple launch their iBeacon and PayPal have released information on their own Beacon project coming in 2015 (possibly). Both are quite neat, and pretty cool technology, they demonstrate well, and when you read about them you do think “wow – that could be cool”. However, the actual use of the technology again doesn’t solve anything, or remove anything from a process (deals or payments).

Even if a Beacon checks me into the store, I still need to have my mobile phone app (maybe even open), I still need to pay at the till using a payment account (maybe PayPal which isn’t exactly cheap or merchant friendly) and I still need an additional way of assigning that transaction to me the customer. With that in mind, is it worth me having Bluetooth switched on and having my phone pinging off beacons?

Even if PayPal manage all this, has it changed my life as a consumer? Probably not. Because there is no added value. All I have done is identify myself to a PayPal system that I am in that store, and at the expense of battery life. There is no added value to the merchant nor to the customer, only a technology that demonstrates well. We must remember too the practicality of all this for the consumer, even if all stores supported beacons, how long before I need to charge my phone? Having my phone constantly pinging beacons via Bluetooth is not good for my battery life, or my sense of security as a consumer. So much so, that most people have Bluetooth disabled on their devices by default, rendering the whole proposition pointless.

Apple beacon is a different approach, it’s not focused on payments and you have to open the app as the consumer, giving you a little more control. However again the concept of only providing deals or information through the beacon app or iPhone won’t stop businesses having to show deals visually in the store or online. Has this made life easier for the business, or actually made it harder? After all, a business won’t want to lose those customers who aren’t on the Apple iPhone platform. What about the majority of smartphone users who are on Android? That growing number on Windows Phone? What about the number of people who don’t even have a smartphone? Do we really expect a store to not provide all those offers exclusively to their iPhone customers? No, so life isn’t easier for the merchant, it’s more complex. No matter the merits of beacons, it still isn’t a game changer for businesses or consumers.

 

Wrapping up someone else’s tech

This is a particular bug bear of mine. There are lots of technologies now out there, and proposed solutions (especially in the mobile payments space) that don’t actually deliver anything at all. Rather, they wrap up someone else’s tech / app, and all they do is pass information to it to semi streamline a process. Now I don’t have anything wrong with streamlining processes in this way, after all, I spent 14 years as a TA doing this for corporates. But does that make my own technology massively valuable? No, it really doesn’t….I don’t want to point fingers at all, but if you again, look at the mobile payment space you will see a fair few of these examples.

 

Payments, tech first, solve a problem second

Unfortunately most technology companies at the moment seem to rush to get a technology together, then try to shoe horn it into some business problem or experience that either it doesn’t fit in, or simply doesn’t work for. The mobile payments industry is rife with this, with a multitude of different approaches to payments, all based around technology first, user experience second and practicality for the business and others a distant last.

 

Look at a problem, and then solve it with technology

I must be “old school” when it comes to creating technology. I still like to have a problem to solve, either in terms of a real business need / driver, or an experience we need to get to before I start designing and creating solutions and new technologies. I still maintain that if you want your technology to work it needs to exhibit all of the following 3 points:

1. Make life easier for you and or your customer
2. Add value to your current process
3. Reduce your costs

If your solution doesn’t do all of these potentially for the majority of your customers, then it’s not worth investing in or using.

Shameless plug here, but when you look at mobile payments, Zwallet is the only mobile solution that ticks all three of these points off, and that’s because it’s a technology and solution that looked at real problems, needs, drivers and experiences first.

ECM access on my phone?

There is a lot being made of ECM and the ways in which users interact with content stored in an ECM repository. There is a real belief that more of us will choose to access ECM content via a multitude of devices, the most obvious being my mobile phone.

With smart phones, such as the iPhone, Windows 6.5 mobiles and now the Google’s Nexus, the real question I find myself asking is “will I really want to access content on my phone?” For many the answer will be “NO”, and for many others the answer will be a very loud “YES”. So what are the real benefits and issues, without getting bogged down in technical jargon…?

ECM on my phone…

Most of us like to be as flexible as possible when it comes to doing work. By this I mean, if I am on the train, instead of wasting my time (maybe sleeping?)  I can get on with some work. With your phone you can check and send some emails, respond to meeting requests etc and in many cases get quite a bit of work done before you are even in the office. The same flexibility is required when we may not be in the office for a while. Obviously my device of choice will be a laptop; however, the flexibility to be without my laptop and use my phone is something that will appeal to many of us… Because of this, being able to connect and work in a “flexible” fashion is very important to individuals and businesses as a whole.

Will my phone interact with our ECM solution?

Basically “Yes”. Most phones these days now come with a web browser (all smart phones do), and if your ECM solution can provide a browser based front end, then interacting with your ECM system isn’t technically very hard. The issue you may well face is using the device itself to navigate around the web pages and download / view the content you want. For me, this is a basic way of allowing content to be shown on a mobile phone. Most of the issues faced then are based around the device itself and what you can realistically achieve on it…

Do I have to use a browser on my phone?

Again the answer is “No”. Using a browser gives us the simplest way of interacting with content on our ECM system; it’s also probably one of the cheapest. However it isn’t the best solution for such a small device, it does make certain features “fiddly” to use, think;

a)      Searching

b)      Checking in / out a file (if you would do such a thing)

c)       Reviewing properties

d)      Reviewing an audit log / history

e)      Tracking in a Case Management / BPM system

This is because you will need to use a lot of clicks and zooming in and out using the browser etc.

The best solution is to provide mobile based applications that can interact with your ECM solution.

ECM mobile applications

If we realistically want to work and interact with our ECM platform, and for that matter, Case Management / BPM solutions, then mobile based applications is the way forward. With the power of smart phones ever increasing, having dedicated applications on your mobile phone isn’t a problem. With mobile applications comes greater flexibility as each application will be specifically designed to be accessed via devices with limited real-estate in terms of space on the screen. This makes using the applications far simpler and easier, which means we are ultimately more likely to want to access our ECM systems via our mobile device.

As we start 2010 it is obvious that ECM solutions need to provide many more ways for users to interact with them. This doesn’t mean a generic web environment / interface, rather a multitude of applications and interfaces that are dedicated to interact with your repository from a particular device.  The trick for providers is providing a single “architecture” for access, which serves all of the different applications that may interact with your ECM repository…