Software built inside a regulated banking environment
We build custom software for banks, lenders, insurers and licensed fintechs. This page covers what we have delivered in banking, how a project is set up so it survives your compliance review, and what happens to the system if you stop working with us.
- [email protected]
What we have delivered in banking
One platform, in production at a Romanian bank. Its case study is published on this site, and the client is named.
- Client
- Salt Bank
- System
- Document generation platform.
- Delivered
- A template editor the bank maintains itself, with control over both the layout and the variables that get filled in, and an API that turns the bank's own data into a finished document. It runs on serverless infrastructure with the services in containers, and connects to the systems the bank already runs.
- Technologies
- Vue 3, GrapesJS, TailwindCSS · NodeJS
Our collaboration with MVP Solution was outstanding. They built a custom solution from scratch tailored to our neo banking needs, showing professionalism and flexibility throughout. Their input was valuable at every step, and the platform now scales to millions of requests per minute. Communication was smooth, and deadlines were always met.
How a project is set up
The questions below come up in every vendor review before anyone looks at the technical proposal. The answers are the same whether you ask them now or in a questionnaire later.
- Who owns the code and the infrastructure
- You do, from the first phase rather than at handover. The repository, the deployment setup and the documentation sit in your own accounts wherever your policy allows it. If you decide to continue with another supplier, you leave with everything and another team can pick it up without our involvement.
- Who has access, and how many people
- A named, small team. The engineers who scope the work are the ones who build it and keep it running, so the list of people with access to your systems is short and does not change between phases. No part of the work is subcontracted.
- Separate environments
- Development and staging run separately from production, with releases promoted between them rather than edited in place.
- Access to production data
- We build against anonymised or generated data by default, and ask for access to production data only where a specific task cannot be completed without it — with you deciding whether that access happens at all.
- What gets recorded
- Where a regulator or an auditor will ask what happened and why, the record is part of the build rather than something added afterwards: who did what, when, and with which inputs. On the document platform this meant the same input still producing the same document later.
What we build
One of these has been delivered inside a bank — the document platform above. The rest are systems we build in the same categories, and we say which is which rather than letting the list imply otherwise.
Templates maintained by the people responsible for the wording, and an API that produces a finished document from data you already hold.
The screens your own staff work in: records with search and filters, forms that show only the fields a role may change, and a record of who changed what.
Account areas and application flows where a customer uploads documents, follows the state of a file, and finds what they would otherwise phone about.
Requests moving through named states, each with someone responsible, a deadline, and evidence of who approved what.
Records passing between systems without anyone re-typing them, with the matching rules written down and failures surfaced rather than discovered.
Reports produced on a schedule from data you already hold, in the format the recipient requires.
Starting a conversation
Write to the address below and the reply comes from an engineer. If you need a vendor onboarding pack or a completed security questionnaire before that conversation, say so in the first email and we will tell you what we can supply.