What we build, and what we deliberately do not
We write the parts of a financial product that are specific to you: the ledger and its reconciliation, onboarding and KYC orchestration across whichever vendors you have chosen, the reporting that a regulator or an auditor will read, and the APIs that connect all of it to banks and payment rails. That work is API-first and boring on purpose — money software should be predictable rather than clever.
What we do not do is hold your licence, act as your compliance function, or sell you a black box for the process that is actually your competitive edge. If a regulated entity is required in the chain, that is you or a partner you appoint. We are the engineering team, and we prefer to say that plainly at the start rather than let it be discovered during due diligence.
Why the regulator shapes the architecture
In financial software the compliance surface is not a feature you add near launch — it decides the data model. An immutable audit trail cannot be retrofitted onto a schema that updates rows in place. Consent and strong customer authentication change the shape of onboarding. Retention rules decide what you are allowed to delete and what you must be able to produce years later, sometimes after the person who built it has left.
So we ask which regime you are actually in before we design anything: FCA permissions and open banking in the UK, NYDFS cybersecurity and multi-state rules in the US, MAS technology-risk and outsourcing expectations in Singapore, PSD2 and GDPR across the EU. The answer changes the build. Getting it wrong is not a bug you patch — it is a rewrite, and usually an expensive conversation with someone official.
Data, residency and the EU question
We are based in Palermo, in Italy, which puts us inside the EU and inside GDPR by default rather than by configuration. For a lot of buyers that is the reason to talk to us: personal and transaction data can stay in the EU, the processing agreement is a normal European one, and there is no transfer mechanism to argue about. When your contract requires data to sit elsewhere, we build for that instead — but we make the choice explicit and write it down, because in finance an undocumented assumption about data location is a finding waiting to happen.
How a fintech engagement runs
It starts with a call about the product and the constraint, not a price. Then a written scope naming what is in and what is out. Work runs in two-week sprints, each ending with something you can use, and the repository is yours in your own organisation from the first commit. For regulated work we write the technical documentation as we go — architecture, data flows, controls — because producing it afterwards from memory is how teams end up describing a system they wish they had built.
On price: rates in New York or London for this kind of work commonly run well above what an EU team costs, and that difference is a real part of why buyers call us. But a market rate is not a quote. We price after the scope, as one number rather than a range that quietly grows.
Where the buyers land
This page is the practice. The market pages carry the regulator and time-zone detail that actually differs: fintech in London (FCA scope, open banking), fintech in New York (NYDFS, audit trail, multi-state), and fintech in Singapore (MAS technology risk and outsourcing). They are different jobs, not the same page with the city swapped.
Questions from this market
Next
- Fintech in London — FCA scope and open banking.
- Fintech in New York — NYDFS and the audit trail.
- Fintech in Singapore — MAS technology risk.
- Custom software — How we build in general.