Integration in a bank: how to avoid hard landings

In banks, one of the fears when it comes to investing in new solutions is integration. And I don't mean technical aspects of it, but the business repercussions of it when something goes wrong.

Part of risk management must always be analysis of the impact of new systems on currently running ones. What must be redesigned? What must be changed? What resources will be necessary? How will the changes affect other connected systems?

And the most important question: what can we do to minimize such risk?

Revolution?

History teaches us that usually, the best way to deal with revolutions is to avoid them. If we only had some time to test a new solution deployed at a limited scale, then - only if works well enough - extend it to full scale. You don't buy a car without a test drive, do you?

Over the years we developed a bunch of different ways of integration with bank legacy systems. Let's take a look at a few of them.

In this article, I would like to focus on the visual part of it, which however have a strong impact on the organization of the whole development and delivery processes in a bank. It's a result of our experiences with delivering processes implemented on our eximee platform to banks like Santander, mBank, PKO Bank Polski or Credit Agricole.

If you are not familiar with eximee platform, you can read some more about its features.

Before we begin we should briefly describe the architecture - which may be a bit technical, but that's okay, we will be fine.

As we can see, eximee is situated in front-end and middleware tiers and serves processes through bank's front-end channels or on its own in all sales channels. What's crucial, eximee is responsible for the visual presentation of the processes.

The easy start

Let's begin with the easiest approach. Eximee - the new system - is simply put and run next to the existing ones. No integration in bank in front-end layers is necessary.

Customers who visit bank's webpages or electronic banking - when they want to start a process - are simply redirected to eximee.

Of course to customers the pages they are redirected to look exactly like the rest of bank applications because eximee's UI reflect the UI of other bank webpages.

As we can see, eximee is situated in front-end and middleware tiers and serves processes through bank's front-end channels or on its own in all sales channels. What's crucial, eximee is responsible for the visual presentation of the processes.

Pros

• the quickest and easiest way of running a new system
• no impact on legacy systems

Cons

• UI duplication, any changes in bank's UX must be implemented in the UI of the processes
• customers may notice the redirection which for the advanced ones is may be a flaw, especially for logged in customers
• bank headers, menus, navigation buttons or sidebars must be duplicated in process forms (or omitted for the sake of simplicity)

That's the easiest way of running a new system with the minimal footprint on the existing environment. This model allows to run new processes, like onboarding, in just weeks.

However, the cons are also significant may be not acceptable for some. Let's investigate the other possibilities.

Seamless integration in bank

This approach requires bank to put some more effort, but thanks to that customers get a way better experience.

The new system is embedded in bank's webpage, electronic banking or mobile application. What banks must do is to develop visual and programmatical seamless inclusion of the new system.

Pros

• seamless integration in a bank - to customers new processes are just a part of the existing systems (i.e. electronic banking)
• no redirection, no page reload
• all elements such as menus, sidebars, headers and footers are provided and maintained by the bank's IT

Cons

• the UI is still duplicated
• since customer can see UI components from both embedding and embedded systems at the same time, they must be 100% identical. This part was easier in the first approach.

This the most popular way of integrating with bank systems.

Worth mentioning is that this way it's easy to integrate widgets - like cash loan calculators with components like sliders - straight from eximee into bank webpages or internet banking.

Micro-frontends - full integration in a bank

The natural improvement of the previous model seems to be eliminating the cons. Indeed, full integration in a bank means that a new system is not just included in a legacy system, but also uses its components.

Embedded processes can use provided elements of the hosting application (a webpage, an internet banking or a mobile app) - but are not limited to them. In our case it means that whichever UX changes banks want to make, they can be done with no interaction with us - the provider of the processes! Since we share the components, the changes made by bank are instantly reflected in our processes.

Pros

• seamless integration with legacy systems
• fully unified UX - owned and developed by bank
• supports modularization and responsibility separation in bank teams

Cons

• none. However, some work must be done by bank.

This is undoubtedly the most mature integration model. The best advantage for the bank is significant control over visual layer of the processes because they use components provided by bank rather than their own.

Modularization

The topic of this article is strongly related to the concept of modularization in banks.

By the way - you may think, that the times of front-end and back-end development are gone - and you'll be romantically mistaken.

Micro-frontends give you the flexibility of dividing applications into smaller functional chunks developed and delivered by different teams. In order not to duplicate the same tasks - like developing UI components which should be identical in all included parts of the GUI - there is a frontend-wide library of components that are used by all applications.

If it sounds like digital transformation and agile teams - that's absolutely correct. Modularization is a natural support for functional teams, which thanks to it may fully focus on their areas of responsibility. But that's a subject for a different article.

Conclusion

There are at least three integration models. Does the fact, that the first one is simple and the last one the most mature, means that we should always consider only the third model? By all means - no! The idea of this article is to illustrate, that the model of integration in a bank should be selected according to bank needs, risks and perspectives. However, what we should be aiming for when thinking about providing the best CX is at least the second approach.

We have successfully deployed all of them in different banks, matching its features with bank's expectations and requirements.

So the take-away message is that when we speak about integration we have flexibility which lets us fit given environment in a bank. But we must consider pros and cons of every approach in the long run.