London, England Financial technology infrastructure
Money software is judged on the day it disagrees with itself.
THE TWENTY FINTECH LTD writes the layer underneath the app: ledgers that balance, reconciliation that can explain its own answer, and payment messages that survive being read a second time by someone who was not there when they were written. One rule holds all three together. Every figure traces back to the record it came from, and the trace ships with the figure rather than being a favour asked for later.
Show us a reconciliation that hurts: [email protected]. Send the month that will not close, or the number two systems disagree about. A person replies within three working days, including when the answer is that this is not work for us.
A balance you cannot derive is a rumour with a currency symbol in front of it.
The working principle of this company
What the company does
Four strands of work, each matched to a SIC code on the register
Each strand is a kind of problem the company takes on, and each arrives the same way: scoped as a document, priced before it starts, and delivered as something a competent reader inside your own team can check.
-
01
Double entry ledgers that hold their shape
Most financial bugs are not arithmetic. They are a ledger that permits a state the business never intended: a posting with no counter-posting, a balance derived from a cached total nobody can reproduce, a correction applied by editing history. We design ledgers that are append only, where every balance is a function of the entries and can be recomputed from scratch on demand, and where a correction is itself an entry with a reason attached to it.
Why it matters commercially: a firm that cannot reproduce a balance from primary records has an audit problem long before it has a customer problem.
SIC 62012
-
02
Reconciliation that shows its working
A reconciliation engine that prints a number and nothing else is an opinion. The useful output is the chain: which internal record was matched to which external record, on what key, with what tolerance, and which items were left over and why. We build matching pipelines whose unmatched pile is the product, because the unmatched pile is where the money actually goes missing.
Why it matters commercially: operations teams do not need a match rate. They need the twelve items that did not match, ranked by how much they cost.
SIC 63110
-
03
Payment message handling that expects to be replayed
Payment infrastructure lives on retries, duplicates, out of order arrivals and partial failures. This strand covers idempotency design, message validation against published schemas including ISO 20022 structures, and the boring discipline of storing the message you received rather than only the interpretation you made of it. If a counterparty asks in eleven months what exactly arrived, the honest answer should be available in seconds.
Why it matters commercially: a duplicate payment is a refund, an apology and a control finding. Preventing it is cheaper than all three.
SIC 66190
-
04
Data plumbing for firms that will be asked to prove things
Hosting, transformation and retention of financial records with the assumption that a regulator, an auditor or a customer will one day ask for a specific record on a specific date. That assumption changes the design: lineage is recorded rather than reconstructed, retention is a policy rather than a habit, and access to production data is a logged event rather than a convenience.
Why it matters commercially: the cost of evidence is paid either at build time or at examination time, and it is far higher at examination time.
SIC 64999
Where the work sits
One layer, deliberately unglamorous
The clearest way to describe this work is to say exactly which slice of the stack it occupies, and which slices belong to somebody else.
Not us
Customer facing product
The app, the onboarding journey, the brand, the pricing page. Owned by the regulated firm or the product company.
Our layer
Ledger, reconciliation, message handling
Recording what happened, proving it still adds up, and keeping the evidence in a form somebody can read later.
Not us
Scheme and bank rails
The card schemes, the payment systems, the banks and the licences that let value actually move.
Read left to right on a wide screen, top to bottom on a phone. The middle box is this company's work; the outer two belong to the regulated firm and to the schemes. The arrows are the direction a transaction travels, not a partnership of any kind.
Method
How an engagement runs
Five steps. The first four each produce an artefact a client can ask to see, which is what makes the method checkable rather than merely reassuring. The fifth is the boundary.
1. A written problem, before a proposal
The first artefact is a page describing the failure in the client's own words: what broke, how it was noticed, what it cost, and who currently carries the manual workaround. If that page cannot be written, the engagement is not ready and we say so rather than selling a discovery phase.
2. Read the data before designing anything
A sample of real records, under a signed agreement, in a controlled environment. Financial data is full of history that nobody documented: the legacy account that is settled in a different currency, the month a migration duplicated three thousand rows. Designing before reading is how consultancies produce beautiful systems that cannot ingest the client's actual file.
3. Fixed scope, written acceptance test
Scope is agreed as a document with an acceptance test in it, phrased so that either party can run it and get the same answer. If the scope changes, that is a new document and a new price, said out loud rather than absorbed silently into a timeline.
4. Handover assumes we are not here
Deliverables include the runbook, the schema documentation, the failure modes we found and did not fix, and the reasoning behind decisions that will look arbitrary in two years. A supplier who is structurally difficult to replace is a risk on the client's register, not a compliment to the supplier.
5. What we will refuse
Work that requires the company to hold client money, to make or advise on a regulated decision, or to represent itself as authorised. Also work where the only available data is a screenshot. The first is a matter of law. The second is a matter of not wasting the client's money.
Reasonable objections
The questions a careful buyer asks first
By keeping it small, well bounded and low blast radius: a ledger design critique, a schema mapping exercise, a single matching rule rebuilt and proved against a month of history. The deliverable is a document or a contained component, and a client can judge the quality of the thinking before anything of theirs depends on it.
With the unmatched pile, not the match rate. We take one closed month from both sides, run the match you run today, and rank what falls out by value rather than by count. That ranking is usually most of the finding: a timing rule that was correct for one currency and wrong for the second, a duplicate window narrower than your slowest counterparty, a fee posted net on one side and gross on the other.
The output is a document naming each break, what causes it, and what it costs a month. It is fixed price, and it is yours to act on whether or not anything further is agreed.
Writing software for a regulated firm is not itself a regulated activity, and the company holds no permissions. The regulated firm remains responsible for its own regulatory obligations, including outsourcing and operational resilience requirements that apply to its suppliers. A supplier who tells you otherwise is selling you a compliance problem.
Work that requires the company to perform a regulated activity is out of scope, and you are told so in the first reply. That boundary is stated in the regulatory position above and in the terms of use.
Yes. Any engagement touching personal data is governed by a written agreement meeting Article 28 of the UK GDPR, signed before access is granted, and worked wherever possible on data that has been reduced or pseudonymised first. The controller and processor split the company operates under is set out in full in the privacy notice.
It reaches a monitored mailbox and a person answers it within three working days, including when the answer is that the work is not a fit. Four addresses split the traffic by subject, so a data protection request and a scoping question do not queue behind each other. The routes and what each one covers are on the contact page.
Public record
What the register says
Every entry below is taken from the Companies House record for this company and can be checked against it. Where this site and the register disagree, the register is correct and this page is wrong.
- Registered name
- THE TWENTY FINTECH LTD
- Company number
- 17061506
- Status
- Active
- Company type
- Private limited company
- Jurisdiction
- England and Wales
- SIC codes
- 62012 business and domestic software development; 63110 data processing, hosting and related activities; 64999 financial intermediation not elsewhere classified; 66190 activities auxiliary to financial intermediation not elsewhere classified
- Officers
- Held on the public Companies House record for company number 17061506. Officer names are not reproduced on this site.
On the office address
The company's registered office is recorded against company number 17061506 on the public register at Companies House, which is the address with legal effect for service of a document. It is the address for service of legal documents. It is not described here as a studio, a headquarters or a place where visitors are received, because that would be a claim about the arrangement rather than a fact from the register.
Next step
Show us a reconciliation that hurts
One paragraph describing what does not add up is worth more than a requirements document. Name the month that will not close, or the figure two systems report differently, and say what it costs you when it happens. A person replies within three working days, including when the answer is that this is not a fit, and points you somewhere better where we can.