London, England Incorporated 1 March 2026
Money software is judged on the day it disagrees with itself.
THE TWENTY FINTECH LTD is a London company working on financial technology infrastructure. Not an app, not a brand, not a front end. The layer underneath: 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.
Read this part first. The company was incorporated on 1 March 2026 and has no trading history to show you. There are no clients on this site, no case studies, no logos, no numbers. Everything below is scope, method and register fact. When there is something real to publish, it will appear here with a date on it.
A balance you cannot derive is a rumour with a currency symbol in front of it.
The working principle of this company
Intended scope
Four strands of work, stated before any of them has shipped
These are the areas the company was registered to work in, matched to the SIC codes on its Companies House record. They describe intent and competence, not a released product catalogue. Nothing here is available to buy today.
-
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 work on ledger designs 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 work on 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. Work in 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 a company with no released product is to say exactly which slice of the stack it is aiming at, and which slices it is not.
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 the only one this company is claiming. The arrows are the direction a transaction travels, not a partnership of any kind.
Method
How an engagement would run
Written in the conditional because no engagement has run yet. This is the process the company has committed to, published so that it can be held to it rather than quietly revised later.
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
Mostly, they would not, and that is a fair position to take. The realistic first engagements for a company at this stage are small, well bounded and low blast radius: a reconciliation review, a ledger design critique, a schema mapping exercise. Work where the deliverable is a document or a contained component, and where a client can judge the quality of the thinking before anything of theirs depends on it.
We would rather write that plainly than build a page implying otherwise.
No. There is no released product, no trial, no sandbox, no waiting list and no pricing. When a product exists there will be a page for it with a release date, and the claim will be sized to whatever it can actually do on that date.
Building 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.
If a piece of work would require the company to perform a regulated activity, it is out of scope. That is stated in the declared limits above and in the terms of use.
Yes. Any engagement touching personal data would be governed by a written agreement meeting Article 28 of the UK GDPR before access is granted, and where possible by 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. The commitment is a reply from a person within three working days, including when the reply is that the work is not a fit. There is no form on this site, because a form that posts nowhere is a lie told with HTML. Details 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
- Incorporated
- 1 March 2026
- Jurisdiction
- England and Wales
- Registered office
- 66 Paul Street, London, England, EC2A 4NA
- 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
- D&B D-U-N-S number
- 234619137
- Officers
- Held on the public Companies House record for company number 17061506. Officer names are not reproduced on this site.
- VAT registration
- [TO CONFIRM: whether the company is VAT registered, and the VAT number if so]
On the office address
66 Paul Street, EC2A 4NA is the company's registered office as recorded at Companies House. 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
Send the problem, not a brief
One paragraph describing what does not add up is worth more than a requirements document. If it is not a fit, you will be told so within three working days and pointed elsewhere where we can.