At Ebury, we have decided to address a long-standing customer requirement by exploiting existing tech capabilities whilst at the same time enabling our employees to be fully creative and learn something new.
About 6 months ago we decided to build a cross-functional team called the “COM-Squad” (Commercial Squad) which is periodically manned by Engineers who wish to take up challenges that will address client requirements efficiently. The team works in a relaxed Agile manner that enables the engineers to self-manage the project, explore & experiment with new technologies in order to learn something new. Product-wise the deliverables’ strategy is driven based on client discussions and identifying technical opportunities that will enable Ebury’s clients to obtain maximum value from our infrastructure.
Whilst Ebury has predominantly targeted Small to Medium Enterprises (SMEs), these have from time evolved to multinational companies operating in more than one locations. As such, their transactional requirements have grown exponentially and clients have started utilising complex software ( #ERP, #Treasury_platform ) to manage their FX and payments needs. One of the long standing issues that most of them were facing is the added cost of reconciling transactions back to their platforms. They have asked us to intervene and offer an automated solution.
Whilst reporting is already offered on our online platform, Ebury Online, that meant that clients would still have to manually import transactions to their systems meaning that they would need to have daily operational processes which added to the transactional costs. At Ebury we could either:
- Outsource to a third party the requirement of fully automating the statement communication to clients
- Do nothing at all since this is not a cost impacting Ebury OR
- Look carefully at our technology stack and find ways to utilise existing capabilities for clients’ benefit.
We have elected to go for the latter.
So the team assigned to this project looked into our existing technology stack and came up with a very efficient solution. The client data needed for reconciliation are already available in Excel and SWIFT MT940 formats on our #cloud-based platform. We have a very strong and stable #API which is already being used by clients for reconciliation purposes and we also have #kafka driven events too. So we thought of combining the lot in order to deliver value to clients.
Ebury is a cloud-based platform. The majority, if not all, of our services are hosted in #AWS therefore it was fairly easy for us to spin off Amazon Elastic Container Service ( #ECS ) tasks to handle subscriptions to the service.
Client-based subscriptions to the service are handled by #kafka_topics. Each consumer is subscribed to a different topic since each one may have different requirements (sFTP or other, timing, statement format etc).
The client Data are obtained over Ebury’s Trading #API. A #microservice handles the authentication and data polling of statements ( CSV, MT940, etc) and once obtained, stores them into the cloud temporarily.
Keep in mind that our data is on the #cloud already so once they are prepared, they can be delivered anywhere. The majority of the clients select to receive those on sFTP folders that Ebury manages & maintains.
OK, at this point one may argue that “this is simply another product offering/solution generating revenue for you”. The answer is no. For various reasons:
- We have a team that was educated to use technologies they‘ve not used before in a manner not previously thought. That’s an investment on our front.
- We have a team that decided on the technologies to use, the way to use them, and were given guidance & support whilst they were free to decide on many elements of the solution.
- The service is not one that we charge for. It’s part of our free client servicing offering. The value of automating our clients’ reconciliation is entirely harnessed by our clientele at our cost. We have simply enabled them to do so by using our existing technology stack in a more efficient manner.