8 September 2026
The list is read beforehand
A payment already moving does not come back. So the screen sits before the instruction, and a model does not sign it.
An executed payment is a poor thing to recall. SEPA has a recall procedure that depends on the beneficiary bank cooperating. Card payments have chargeback windows and a rulebook around them. An on chain transfer has nothing at all. The only control that works reliably under all three conditions is the one that happens beforehand.
So the screen sits before the instruction, not as a report the next morning.
At onboarding the company, the beneficial owners and the documents are recorded. On every single instruction after that, payer and beneficiary are checked against the name lists.
A hit stops the instruction. And here begins the part no software takes off your hands: name lists produce false positives in volume, because names resemble each other and transliterations diverge. A person decides whether the hit is real. A model reads the list faster than any human. It does not sign the decision.
The entry records which list, which vintage of it, and which person were involved. That sounds like bureaucracy until the first time somebody asks why a particular payment went through in March. Without the list as it stood then the question cannot be answered, because today’s list is a different list.
A later refund does not overwrite that line. It is a new line beside it.
This is the control set Newton Pay is built around.