Demystifying financial applications creation
I’ve been working at Finastra for more than 5 years now, and I’m baffled when my colleagues from outside the financial industry think I’m working on a Nuclear Fusion Reactor, joking at how complex this sector is.
Granted, Finance is a broad sector and security is at the core of everything we’re doing. But it’s also a time-proven field, where most of the big issues have been solved, and now patterns emerged out. I strongly believe that nowadays, with the move to Open Banking, anyone could make an application for a Bank or Financial Institution, with or without Financial background. The hardest part really is knowing the regulations of each country 🙈.
That being said, don’t expect that by the end of this article, you’ll be a financial genius (I, for one, am sure not 😆). What we’re going to do here is create a sample Corporate Banking application:
You’re all familiar to Retail Banking : it’s what you use, probably on a daily basis, to check your bank accounts, transfer money to friends and family and so on. Simply put, Corporate Banking is the same, but applied to a Company. Whether you’re a multinational or a startup, you still need to check your account balances and transfer money. But you also have needs that are not required for an individual such as processing payments from or to in batch (for example : paying employees or making a request for payment of a monthly membership), Trade and Supply Chain Finance and so on…
This article will not go in depth to see how the supporting sample app was done step by step, but rather detail some of the milestones and big concepts. Of course, you’ll be able to check at anytime the entirety of the source code on Github:
Register an application on Developer Portal
As defined in our glossary, an application is “The custom collection of APIs, SPIs and/or Datasets that you create through the Application Creation Wizard on FusionCreator.”
Do not confuse it with a client application or end user application, which is what you are probably using everyday. It could be a web application, mobile application or even an application for an IoT device such as a car or a TV ! And all of them would be referenced under the FFDC application as they would all be using the same set of APIs, SPIs and Datasets!
If you are not familiar with how to create one on our Developer Portal, here is a great summary:
Once you have your client ID and secret pair ready, let’s use them in a server side application.
Authenticate
Finastra’s Developer Portal uses OAuth 2 to authenticate, which is nice, as it’s a standard, and a lots of libraries have been developed for different languages and frameworks since its inception.
The different values you would be required to provide to such libraries would be the following:
- Client ID: detailed in the previous section
- Client Secret: detailed in the previous section
- Issuer: https://api.fusionfabric.cloud
- Scopes: List of scopes required by your chosen APIs. In the case of the one we selected previously, there was no scopes so it would be empty
- Reply URL: The url to return to once the authentication flow is finished, at dev time this would be something like http://localhost:3000
With this, you’ll be able to delegate the login page of your application to FFDC and eventually, to the financial institution that will be using your great software!
While working locally though, you will see the following login page, from the Sandbox tenant:
Use one of the following pairs of credentials to log in :
- ffdcuser1:123456
- ffdcuser2:123456
What we did in our sample app is to use a module for OIDC (OpenID Connect) that we created internally and provided publicly for the community.
Confusingly, OAuth2 is also the basis for OpenID Connect, which provides OpenID (authentication) on top of OAuth2 (authorization)
This module’s documentation can be found below:
This module is basically a wrapper around openid-client library, which is OpenID certified.
It is to be used with the NestJs framework, which we like to use internally as it’s robust and very scalable for server-side applications. Yet the point we want to make here is not to say that everyone should use NestJS, we’re not trying to spark a technology debate. Use what you need for your use case ! But if you are already using NestJs, we thought it could interest you 😉
Query for data
So you have successfully authenticated yourself, and the result of this process gave you an access token. With this, you are now able to query the aforementioned endpoints and retrieve data!!
Let’s circle back to our API, and say we would like to query the first endpoint, listing the accounts. Only thing to do is to make an HTTP request to https://api.fusionfabric.cloud/corporate/channels/accounts/me/v1/accounts?accountContext=ViewAccount and adding an “Authorization” header with “Bearer ${TOKEN}”, replacing ${TOKEN} with the value of your access token of course!
Bearer authentication (also called token authentication) is an HTTP authentication scheme that involves security tokens called bearer tokens. The name “Bearer authentication” can be understood as “give access to the bearer of this token.”
Theoretically you could save the access token on the front-end, to enable the possibility for your SPA to make such request and target the APIs directly.
We would strongly argue against doing so as you should never trust your front-end (EVER).
A more secure way to query the APIs would be to keep the access token on the server, and have it be a proxy for doing the requests. Through a session or other mechanism to identify who is making the request, the server would automatically add the bearer token as authorization header to required requests!
Your front-end is not exposed but it can still retrieve data!
Pseudo code from the client would look like this:
Once again for the NestJs users out there, we come to the rescue :
This module is a wrapper around the popular library node-http-proxy. It will be looking for a user object (standard with passport) on the request, and assign the access token to the authorization header !
On top of making the requests to the APIs from the server and not the front-end, in some use cases, you would be tempted to use technologies such as GraphQL to retrieve your data.
We’re not suggesting to use it ALL THE TIME, again, use what you need for your use case 😉. But if we take the Accounts Balances & Statement API, using aggregation on the backend is justified !
Indeed, the endpoints are resource oriented, and information is segregated by design.
When retrieving a list of accounts, you’re not retrieving the balances of those accounts. You can also get a list of the balances, but then you won’t get the account informations other than its ID. Getting the informations/balance/statement for one account is decoupled as independent calls. Which is a good pattern, you only query for what you need.
But the drawback is that your front-end will make 1 request for the list plus n*2 requests per account information and statement to display. Which if you simply want to display 4 accounts, would require 9 separate requests from your front-end.
Using technologies like GraphQL, you could write a query such as the one below and have those 9 requests be done on the server and only one request would ultimately come from the client :
Besides the obvious gain in front-end logic, not having to aggregate the data, you would gain a lot of load time because making a backend-to-backend request will always be more performant than frontend-to-backend !
Additionally, you would be able to re-use this in your mobile application, and be even more performance savvy by requiring a subset of all the information through specifying only the fields you need in your request. Every bit of information saved matters when developing for mobile 😉
If you’re not familiar with the concept of BFF (Backend For Frontend), I would advise reading this article
Use Finastra patterns for UI
So you can now log in and retrieve data. Let’s talk about molding this data into a formidable UI!
Like every major player out there, Finastra has been creating its own Design System.
If you’re part of a big company, you would have your own Design System as well. If that is not the case, or if you’re curious about how we do things, have a look at this article:
As you can see, the big difference is that we focus on Financial components that play hand in hand with the data from our Developer Portal.
On top of that, through our experience of app making, we carved out UI patterns to easily make the best choices of how to layout your application!
Closing words
Lots of concepts were tackled here, and it would seem that my point of demystifying complexity was lost in translation, but on the contrary : from all the concepts I went through in the articles, none require financial knowledge or background. Most (if not all) of those concepts are industry standards and used or heard of by 2020 web developers.
Through our Developer Portal and our Design System, we at Finastra are trying to hide the business complexity of creating an application, leaving you with only the technical skills to hone to be the next billion dollars Fintech unicorn!
Now that you fully understand the basics, you can go ahead and explore the rest of what Finastra offers regarding Corporate Banking:
If you liked this article:
- Add some 👏
- Share it
- Follow our Medium Publications
- Try to make some apps using our Developer Portal & Design System
- … or all of the above 😆
Till next time !
