Architecture and tooling for systems that have to survive an audit.

Most software in regulated domains fails the same way: compliance is treated as a review gate at the end instead of a constraint at the start. Everything here assumes the opposite — traceability, evidence and explainability as structural decisions, made on day one, testable.

Client onboarding and due diligence · document lifecycle and lineage · counterparty matching · automated financial reporting · AI governance

EU AI Act · ISO/IEC 42001 · DORA · AMLD · MiFID II · PSD2/PSD3 · GDPR

Python · FastAPI · PostgreSQL · Node · Odoo · React · Typst
LLM orchestration · structured extraction · deterministic rule engines · evaluation and audit logging

• Verify before asserting. A claim about a system comes with the file and the line it came from, or it is labelled a hypothesis. A comment is text about the code, not the code.
• Adversarial validation. Decisions go through multi-model review — thesis, antitheses, synthesis — before they are locked in. Fluent agreement is a risk signal, not a result.
• ADRs by default. Context, decision, consequences. Written when the decision is made, not reconstructed afterwards.
• One change, one check. If an approach fails three times, the approach is the problem.

The probabilistic component of a system is the part you have to justify. Most of the design work is deciding what a model is allowed to decide, what stays deterministic, and how every output is logged so someone can reconstruct it two years later without asking anyone.

Two decades founding and running companies before building systems for them. Hardware and software R&D, cross-border manufacturing, and several years on the buy side: investment analysis, due diligence, deal work.

I have raised institutional capital, which means I have been the one audited rather than the one building for auditors. Most of what I design now, I once had to do by hand.

validador-cadena-verifactu — Verifies the integrity of invoicing record chains under Spain's Verifactu regime: hash per record, chaining, and the twelve points where the official spec does not determine a single behaviour. Written in Spanish, on synthetic data. Why it exists

calculo-titularidad-real — Calculates beneficial ownership through corporate chains under Spain's Ley 10/2010 and under the EU AMLR, comparing both regimes. Written in Spanish, on synthetic data. Why it exists

plazos-conservacion-pbc — Calculates the retention status of AML documentation under Spain's Ley 10/2010 and under the EU AMLR, comparing the six possible readings. Written in Spanish, on synthetic data. Why it exists

plazos-actualizacion-pbc — Calculates the next mandatory review date of customer information under Spain's Ley 10/2010 and under the EU AMLR, comparing six readings and listing the decisions needed to resolve each indeterminate result. Based on AMLA's draft guidelines. Written in Spanish, on synthetic data. Why it exists

registro-examen-especial-pbc — Checks whether the record of an AML suspicious-activity review in which an AI system may have taken part is complete under Spain's Ley 10/2010 and the EU AMLR, and who had to decide the report under each regime. The AI system is treated as a black box. Written in Spanish, on synthetic data. Why it exists

registro-cambio-agente-dora — The first on DORA, and the one that treats AI agents as actors in an ICT change: checks the record of a change an agent took part in against DORA and Delegated Regulation (EU) 2024/1774, under the full and the simplified regime, and shows what that record can — and cannot — prove. Written in Spanish, on synthetic data. Why it exists

Notes. Tools I needed and had to build. Nothing here comes from anyone's production.