I build payments infrastructure, and I write about the gap between what a specification asks for and what the data will actually support.
Most recently: a corporate treasury and payments platform — an ISO 20022 file rail with pain.001 out and pain.002 back, detached signatures over the messages, dual control on release, sanctions screening against real designation feeds, and a double-entry ledger underneath it. Around eighty-eight thousand lines and fifteen agent workflows, built to production shape without a production bank.
The writing below is about the parts of it that did not work, and what measuring them showed.
Engineering · Machine learning in regulated systemsFour times the specification asked for a model the data could not support
A circular label that passes every offline test. An ensemble over two inputs that do not exist. A similarity score no regulator would accept. A formula that was dimensionally wrong. What made each refusal defensible was the number attached to it — including a baseline measured at AUC 0.47, below chance.
Estimation · Negative resultThe estimator that got worse the more data I gave it
Sixteen times the data, half the standard deviation, double the bias. A parameter estimator converging confidently on the wrong answer while every diagnostic improved — and a miscalibrated refusal threshold that hid it by refusing everything. Two explanations proposed, measured, and discarded.
What I work on
ISO 20022 message profiles, and the November 2026 structured-address deadline that 44% of banks are reported to be behind on. Bank file rails — delivery atomicity, signing, and reconciling the answers a bank could not give. Payment controls that have to survive an audit: idempotency, maker–checker, velocity ceilings, segregation of duties. And the estimation questions underneath any system claiming to see a state nobody measured.
If you have a payments problem with a date attached to it, get in touch.