Authentication, Authorization, and Intent In ERP Banking.
Providing embedded banking capabilities into a client’s ERP platforms is becoming more and more important. In order to deliver a seamless embedded banking experience, there are many moving parts that have to come together.
In this article, I will outline how FISPAN ensures authentication, authorization, and intent are at the core of our processes and services.
Authentication and Authorization
Let’s first start by defining these terms. In order to do this, I am going to borrow some language from our IAM partner, Auth0 because they do the best job of explaining it.
Authentication:
“In authentication, a user or application proves they are who they say they are by providing valid credentials for verification. Authentication is often proved through a username and password, sometimes combined with other elements called factors, which fall into three categories: what you know, what you have, or what you are.” This is the same idea as logging in to online banking with your username, password, and potentially a multi-factor ID of some kind.
Authorization:
“Authorization refers to the process of verifying what a user has access to. While often used interchangeably with authentication, authorization represents a fundamentally different function. In authorization, a user or application is granted access to an API after the API determines the extent of the permissions that it should assign. Usually, authorization occurs after the identity is successfully validated through authentication so that the API has some idea of what sort of access it should grant.” This is the idea that once you are logged in, there are only certain bank accounts you can see and certain actions you can undertake. Generally in a commercial banking context, we think of authorization as user-level entitlements or the scope of what any given user attached to that bank client profile can perform.
Or an even simpler explanation comes from OKTA:
“You can think of this like hotel key cards, but for apps. If you have a hotel key card, you can get access to your room. How do you get a hotel key card? You have to undergo an authentication process of sorts at the front desk in order to get it. After authenticating and obtaining the key card, you can access resources across the hotel.” 
Interesting Challenges in E2E Authentication for ERP Connections
Because FISPAN sits in the middle, directing traffic between the ERPs and the bank’s resources, there ends up being a multi-legged authentication chain. As a result, FISPAN must ensure that it can authenticate the client application to which it is trying to communicate with. The bank, on the other hand, is required to be able to authenticate which client is making the requests via FISPAN, in order to send them to the bank.
Client Level Scopes (Entitlements)
The table below shows the standard pattern of implementation. From the bank’s perspective, think of FISPAN's entitlements working in the same way that direct-file-send works for your clients today. Meaning, the bank only offers a client level scope on entitlements versus an account level scope like it would in a portal. ERPs themselves have varying capabilities to restrict who can see the ledger balance (non-real time view of each account). While the client can control who sees the reporting screens, they cannot currently select a different set of visible accounts at the user level.
For NetSuite:
In addition to being multi-legged, there is an interesting interplay between bank entitlements and ERP user entitlements, but effectively, this is the exact same pattern that banks use to provision H2H/SFTP connectivity clients. The client both authenticates themselves with a certificate and private key, but the authentication happens at the client level, not the user level. Banks either allow the clients to trust their user level controls or enforce user-level controls on the bank side, where the STP file is paused and awaits a release or acknowledgement as part of a user authenticated session on a bank platform.
FISPAN’s model is an improvement to this model since in addition to this existing auth flow, we are also able to overlay weak user authentication based on the access management and controls in the ERP. We can then identify and name the individuals sending certain transactions.
Application Level Scopes Versus User-Level Scopes
It should also be noted that the current industry best practice in using some kind of token to connect two business applications is done with a “client level” scope as opposed to a user-level scope. This is the case for a number of reasons; one being that you want to set a single, appropriate scope for the application pair and second, that you don't want to have to maintain multiple user-level connections to each companion application. Today, business processes such as SFTP file transfers work under this premise as well.
However, not every ERP is created equal in terms of entitlement management for users, and not every client is equal in how diligently they leverage these capabilities. While this doesn't hurt our ability to authenticate the ERP, it does challenge its utility as a strong authorization tool.
Today, the only way to make this model more granular would be to try and recreate the entire bank portal model within FISPAN’s platform and ask clients to try to match our idea of entitlements with their much less granular user model in each ERP - which outside of being impractical, would likely create a false sense of security versus other solutions.
Bank services can support three-legged OAuth as well as the ability to leverage the bank’s federated SSO tools. With some clients who have this kind of infrastructure, we can do two things: process all transactions with the bank under a user-level scope (OAuth) to create a client-level entitlements experience on the server side, or, where the adaptors rely on customer JavaScript applications, we can embed bank SSO to allow all FISPAN read and write UIs to be delivered as a user authenticated session and potentially filter viewable data by client. As banks deliver this, we are more than happy to work on migrating your program with FISPAN to this model.
Authentication vs. Authorization vs. Intent
Another area of confusion stems from the concept which I will call “intent.” When a client wants to transact with the bank, we want to confirm that they are who they say they are (authentication), that they are allowed to perform that transaction (authorization), and that the transaction they tried to perform was actually what they wanted to happen (intent).
The bank really cares about intent for a number of reasons, but one is that from a client experience perspective, you want to provide controls to make sure nothing has been doubled, transposed, or filled with typos along the way. Even more importantly to the risk and compliance people, is that an immutable and discreet confirmation of intent changes the balance of liability for any unexpected payment outcomes.
In the old world of ERP connectivity, that was heavily reliant on SFTP file exchange, our trusted friend “the certificate” did a lot of heavy lifting as it solved all three problems.
The bearer of the certificate is obviously the client. Whoever the client allows to touch the certificate is obviously authorized to transact and the message is signed and encrypted by the certificate. This means that the intent couldn’t be altered on its journey and more importantly was “stamped” as legitimate by the client.
The Future is Out of Band Confirmation
Using certificates as a method of intent confirmation is a bank-friendly solution but not necessarily the best solution for most businesses. Very large businesses who have invested the most into their ERP entitlements and workflows will appreciate the efficiency of this, however that creates a lot of other businesses that will need other services.
While the old model may work perfectly in a two-party system trying to communicate over the open internet, the future of treasury and banking is multipart, as clients leverage more and more applications who themselves are cloud-hosted, use dynamic IP ranges, and rely on their own different authentication and authorization models with banks. The push for open banking globally is also multiplying that change around the world and bringing about new models for out of band communication. 
FISPAN has its own suite of out of band transaction confirmation solutions in mobile, web, and other channels. Ideally this would require federated SSO/OAuth type infrastructure for the bank. Separately, many banks have the ability to pause an inbound file and hold it for an authorized release within their own portal environment; this is a very strong solution used widely by our banks with their clients. For clients who do not want an out of band transaction, we can leverage an indemnity agreement to allow clients to execute with straight through processing. Most global banks have some of these tools available as part of their open banking suite.
I hope this article provides you with a little more colour behind how authentication, authorization, and intent work together at the root of FISPAN’s processes. Providing embedded banking capabilities into a client’s ERP platforms is what we do on the surface, but we have lots of passionate people behind the scenes who are experts in working with our client’s unique infrastructures.
If you’d like to learn more and chat with a FISPAN expert on this topic, feel free to contact us.