Finastra’s developer portal : More than just APIs

Finastra’s Developer Portal gives developers the power to use complex and specific financial functionalities to create applications.

In a previous article, we’ve detailed how to create an application using APIs only. Today, we’ll focus on the other building blocks that you can find in our Developer Portal. We fundamentally think that a Developer Portal should not only be an API Gateway. This is of course very useful, but it’s not enough. You need a platform !

These are the fundamental building blocks that we believe are necessary in a future-proof Developer Portal :

• APIs
• Events
• SPIs (Service Provider Interface)
• Data partnering

Let’s dive into each and explain why they matter !

APIs

Abstract illustration of an API call between a Fintech (left) and a Bank (right)

No need to explain what an API is for developers reading this article. As for the rest of you, think of it as a request-response type of situation. Somebody asks for information, creates a request, and information comes out of the system through a response.

An example of that is Monotto, which created APIs on our Developer Portal for Fintechs to use. Have a look at their success story in this short video :

Monotto's RoboSave: Automating financial stability through artificial intelligence |…

TLDR; APIs are the way to get informations out of a system and put informations into a system

Events

Abstract illustration of an event being triggered from a Bank (right) and dispatched to Fintechs (left)

An event is kind of the opposite of an API in terms of flow, as it originates from a process that is running inside of the Bank’s core system.

Eventing is used to push information from the core banking system to anybody who is looking at that data. To be “looking at data” one would need to register/subscribe first to get notifications.

This eventing mechanism allows the subscriber to be informed in real time and do something about the event, but not necessarily to respond back to the bank.

Find an example below of an integration of events from FusionFabric.cloud, that was built on top of Salesforce Financial Services Cloud :

Fusion Credit Connect

TLDR; You need events because you cannot see, know or react to things that are happening in a system private to you

SPIs

Abstract illustration of a Bank (right) calling an SPI from a Fintech (left) during a process to potentially alter that process

SPIs inverse the relationship with APIs, but not the same way events do.

Basically, they allow for extension or change of behaviour of a system. Any of our product can define a place in their execution to call for an SPI. As a developer, you can provide an endpoint that you have developed to be requested upon the event is triggered.

Let’s take an simple example with Fraud Detection :

A developer has registered its SPI on a fraud detection event inside of a Payment Solution. A payment is being processed, and in place of using the core system’s way of checking for fraud detection, the bank is going to make a request to the SPI. In this way, the fraud provider would be able to return a fraud result, that the payment system would then use in the decision making in the rest of the process, ultimately leading to not processing the payment if the result leads to that conclusion !

TLDR; SPIs are the way to extend or change the behaviour of already existing APIs.

Data Partnering

Abstract illustration of a Dataset coming from a Bank (left) being consumed by a Fintech (right)

Data partnering solves the issue of providing large amounts of data securely to data scientists, to enable them to train Machine Learning models.

As a data scientist, coming across meaningful volumes of data to be able to train models is very hard.

As a bank, your data is gold, and you cannot allow it to be publicly accessible to anyone, but you would benefit from outsiders’ Machine Learning algorithms.

Finastra is trying to bridge the gap between banks and data scientists through an API like contract, where data scientists can require access to Datasets, seeing the format, and a sample of the data beforehand, and Banks can grant consent on an individual basis. Once approved, the data flows in a protected way, being point to point encrypted. Finastra actually never sees this data.

TLDR; Data is mandatory to train a Machine Learning model

Those are the four building blocks with which you can basically build anything ! Let’s see some examples of how to combine all of these together to create a great customer experience !

Empathetic Banking

Empathetic Banking user flow

• Customer walks in branch.
• Cameras send an event to bank officer systems, retrieving customer’s history using APIs. AI systems retrieve data (Get Accounts) about the customer with insights on what products to offer customer. Trained from DataPartnering Data (Accounts, Transactions, etc…)
• Intelligence is gathered from external systems using SPIs (Account Lookup).
• After leaving the branch, IoT devices like the customer’s car and home provide follow-up by receiving events (Marketing) and invoking APIs (Offers).

Banking as a service

Banking as a Service user flow

• Bank creates new revenue stream as the engine for non-financial company SolarWorld that embeds financial services in its consumer app.
• SolarWorld app does Loan Origination, KYC and Funding using APIs. SolarWorld provides fraud detection using SPIs in payment to make fast lending possible.
• SolarWorld app can tailor offering to consumer using AI-based predictions thanks to data and to geo-location and uses events to make them pop up.

That’s it for today !

I hope this was informative 🤗! If you want to go more in depth, go explore our Developer Portal :

FusionCreator Developer Portal

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 only one of the above 😆

Till next time !