Securities Regulator → AI Architect
I build the AI systems for an industry I used to regulate
Governed AI orchestration for regulated finance: auditable pipelines where the model interprets and deterministic code executes, validates and logs. Most people in this field have the engineering or the domain. The work below is what happens when one person has both.
Every system on this page is built on that boundary.
Selected work
Retrieval grounds the request, the model drafts inside a fixed contract, five deterministic gates and a policy check stand between it and the database, and every stage is logged. Eleven of eleven gates hold under adversarial testing. Runs on three interchangeable backends, from a frontier API down to a 4B model on local hardware.
Twenty interactive topics arguing that in regulated analytics the model is the cheap part and the hard problems sit downstream: metric ownership, certification, approval design, cost. Where I put the domain view in writing.
A governed multi-agent assistant for AML and financial-crime regulatory work: supervisor, retrieval, structured-data and analytics sub-agents, a validation judge and human-in-the-loop. Generalizes an approach proven on a live 2026 regulatory delivery.
Lab
Hardware and real-time graphics. Not the moat, but the reason I trust myself at the boundary where software meets physical things.
Hands-free control of a wall-projected thinking surface. MediaPipe over an 850nm IR camera, with an ESP32 and BNO055 wristband as the programmable Mark II.
A local WebGL visualizer with six engines, built after a streaming API closed. Beat-locked rather than strobing, Wii-driven, designed for mixed neurotypes.
I spent four years as a capital-markets regulator at Peru’s securities authority, designing IOSCO-aligned rules, authorizing funds and supervising transaction monitoring. Today my work is AI automation inside a global payments network: deciding what should be automated, designing the system that does it, and making sure someone can audit it afterwards.
That combination is the point. Current LLM engineering on one side, real regulated-finance domain knowledge on the other. The systems I build are useful because a model interprets, and trustworthy because deterministic code executes, validates and logs.
I think associatively and across domains, which is where most of my useful ideas come from: a pattern in one field turning out to be the answer in another. It is also why several projects here are about getting out of a chair and thinking in space, on a wall, by hand. I would rather build tools that fit how my mind works than keep paying the tax of fighting it.