Account Creation Capabilities Management
This document provides an overview of the design decisions made for the first stage of the Account Details Service (from now on ADS), a service that will provide a new way of getting and maintaining Ebury's account creation capabilities. The document's goal is to provide visibility and gather feedback from the Technology Department at Ebury.
Problem Description
Our users need to create accounts in Ebury.
In order to allow it we need a centralized service that can provide the truth about which account creation capabilities Ebury has. With account creation capabilities we refer to the supported countries, currencies for each country and if the account can be created automatically by the system or if it will need human intervention.
We also need to store the information needed to create the accounts on third party services because in a later stage ADS will take care of that.
Background
Right now, Ebury is investing in projects that improve cash management. One of them is the creation of dedicated accounts for our customers. The goal of the project is to improve the reconciliation process, laying the foundation for the functionality that will allow our customers to have several balances (salaries, suppliers, collections, etc), and providing self-serving account creation functionality to our customers.
To get that automation level the system needs to know Ebury's account creation capabilities. At the moment of writing this RFC, account creation capabilities are stored using spreadsheets that are managed by the Operations Team (Reconciliation). This process is mainly manual and prone to human error giving a bad experience to our customers. Furthermore, from a security standpoint, it’s easy to insert malicious data in the spreadsheets and the information can be easily leaked.
Solution
To achieve the goals exposed in the background section, we propose to extract the dedicated accounts (bank account mask) functionality from BOS into a small independent service. The new service will also implement the Product Team requirements and fix the problems that we have been dealing with. Those problems range from the lack of validation of BICs and IBANs to the need of Support intervention to perform account activations.
The service will be accessed through a RESTful API. It will use it's own database for persistence. And will reside within Ebury's internal production network. It's only meant to be directly accessed by our other internal applications.
The information stored in ADS is required by processes like reconciliation, payment routing, trade funding, etc. The internal services that execute them (like BOS and FXS) will fetch it directly from ADS.
For external applications that need access to the new internal services' information we need to put in place user authentication and rate limiting functionality. We don't want to add that functionality to each of the new services. So to avoid adding it we will delegate that responsibility to the existing Ebury public API by passing through it all those external connections to the internal services (ADS in this case).
We currently have three applications that will pass through the API to reach ADS:
-
EBO: This is an Ebury service, but it's exposed to the outside world. Hence we shouldn't give it direct access to the internal infrastructure. In addition the user journeys exposed by the API and EBO should be the same.
-
Salesforce: We can't manage it's infrastructure because it is hosted externally. We also need to setup an authentication endpoint for the connection with our internal infrastructure. To avoid having to do it everywhere it should pass through Ebury's API.
-
Website: In the future we want to display Ebury's account creation capabilities in our corporate web site. To keep the information up to date we plan to pull it from ADS. This is an application that is also exposed to the world so it should also access ADS through Ebury's API.
Capabilities
Ebury's capabilities are described using issuers and rules.
Issuer Details
An issuer represents a real world BIC belonging to an entity that can issue accounts.
An issuer detail represents an issuer capability to generate accounts for a country. They can also allow fully automatic creation of the accounts or require human intervention.
An issuer can create accounts in different currencies, depending on existing rules related to it.
Rules
A rule represents the capability of an issuer to issue accounts for a currency and the restrictions that may apply.
ADS API
On the first stage ADS's API will only expose issuers, rules and bank-id codes.
Issuers will be exposed through the /issuer-details endpoint. Rules will be exposed through the /rules endpoint. And bank-id codes will be exposed through the /bank-id-codes endpoint.
Ebury API
On the first stage Ebury's API will expose only ADS capabilities functionality.
Security
The user permissions are controlled by predefined roles. Those roles are obtained from a header in each request.
That is enough because the service will reside within Ebury's trusted internal network.
To improve security, when the Identity Service is ready ADS will obtain the user role from the JWT.
Alternatives
An alternative approach would be to implement the feature in BOS. But that clashes with our goal of making BOS smaller and easier to maintain. We would also have to deal with the with the constraints of Python 2.
Caveats
N/A
Operation
This service will be run inside the production private network and is intended for internal access only. The functionality that needs to be exposed to the outside world will pass through Ebury's API.
Our Support and Operations teams will have access to the service's REST API. It will provide read, query, create and update functionality, getting rid of the need to provide access to the database to those teams.
Security Impact
ADS user permission system is a security risk but it's mitigated by the fact that ADS will reside inside Ebury's internal trusted network. Once the Identity Service is available it will be resolved by using the JWT.
Performance Impact
During the first stage we don't expect any performance impact.
Developer Impact
ADS auto generates a Python client library that is included in Ebury's python package index. It will reduce the time needed to integrate ADS with other Ebury services. It's name is account-details-client.
Data Consumer Impact
ADS stage 1 should not have any consumer impact.
Deployment
ADS uses continuous deployment through Jenkins.
Dependencies
N/A