Greenfield open banking pipeline that fetches, stores, manages, classifies and categorises account data from most high-street and challenger banks, self-hosted with automatic burst into the cloud.
In-Sync Group is a fintech in Elstead, Surrey. We had contracted there once already, from September 2016 to December 2017, on internal CRM work against the then-unreleased HMRC self-assessment APIs, a mileage-tracking app for self-employed workers on iOS and Android, an Angular 2 web app for on-boarding workers on site, and a second one for workers finishing the same registration at home.
He came back for a greenfield build: a system that fetches, stores, manages, classifies and categorises open banking data from most high-street and challenger banks, over open banking APIs and others alongside them.
One note on dates. The CV prints this engagement as January 2021 to June 2020, an end date that falls before the start. We have kept the start month and left the end open rather than guessing at it.
Open banking data arrives on someone else's terms. Each bank exposes its own reading of the standard, consents expire on a clock you do not control, and rate limits and downtime belong to the provider. A pipeline reaching most high-street and challenger banks has a large surface of things that can fail independently, and it has to keep working while several of them are failing.
Classification is the harder half. An account feed is a stream of terse free-text descriptors written by banks for their own purposes, and turning that into categories a product can reason about is where the accuracy lives. Get it wrong and the customer sees it on the first screen they open.
Then there is where it runs. The system was to be self-hosted in-house, with the cloud used for burst rather than as the default home for the workload. That removes the usual assumption of elastic capacity everywhere and pushes the design towards something that packs onto fixed hardware and spills outward under load.
We built it as microservices on .NET Core, with Azure Functions and Azure Service Bus carrying the asynchronous work, packaged with Docker and orchestrated by Kubernetes. Kubernetes is what makes the hybrid honest: the same workloads run on the in-house cluster and spill into Azure when demand rises, with one implementation rather than a second cloud-only path to keep in step.
The front end was Vue.js. Source control spanned SVN and Git, which is what a new build sitting next to an older estate tends to look like.
The pipeline covers most high-street and challenger banks. For a product built on open banking data that is the number that decides everything downstream, because coverage determines whether a customer can connect the account they actually bank with.
It runs on In-Sync's own hardware and scales into the cloud on demand, so steady-state cost sits on owned capacity and elastic cost only appears when the load does. The CV gives no figure for accounts connected or transactions classified, and there is none here.
- Microservices
- .Net Core
- Azure Functions
- Azure Service Bus
- Docker
- Kubernetes
- Vue.js
- SVN
- Git
- Open banking APIs
Working on something similar?