Pre-submission validation against the ESMA disclosure templates
In buildESMA securitisation disclosure validator
In regulatory reporting, a false pass is a filing failure and a false fail wastes a compliance team's day. Both are expensive, so the rule set is the product and everything else is plumbing.
The problem
Securitisation disclosure runs on published templates with hundreds of fields, nested records and a schema that has to be satisfied exactly. Which template a loan tape belongs to is not written on it — the annex follows the asset class, not the deal label, and getting that wrong invalidates everything downstream.
Submitting to find out is the normal workflow and a bad one. The useful place to catch a defect is before submission, and the useful output tells an analyst which defects are theirs to fix and which belong back with the servicer.
The system
A workbook is dropped in, and the template is inferred from how many of its columns each candidate can bind through a known alias. The margin over the runner-up is shown and the choice can be overridden in one click, because detection is a judgement and the interface presents it as one rather than picking silently.
Fields are mapped, validated against the rule set, and emitted as XML that is checked against the published schema in the browser.
Four asset classes are covered — automobile, residential real estate, corporate, and commercial real estate, the last with tenant records nested inside collateral records — all tying out against the investor report template.
Stack
On screen
Progress
Where the build stands
In build. It runs end to end on synthetic loan tapes, entirely in the browser with no backend, no database and no persistence — a refresh clears the session, which is intentional for a tool handling loan-level data.
The checks are the substance: rule engine unit tests across all four templates, every extracted XML path walked through the schema type graph, and generated output validated against the published schema rather than against an approximation of it.
- Validated against the published schema, not an approximation
- Every extracted XML path walked through the schema type graph, with output checked by a real XSD validator in the browser.
- The machine's judgement calls are shown, not hidden
- Template detection reports its margin over the runner-up and can be overridden in one click.
- The rule set is tested, not asserted
- Rule engine unit tests across all four asset class templates.
What you take
This is what a compliance-shaped system looks like when it is designed properly: the rules are explicit and testable, the machine's judgement calls are surfaced to the user rather than hidden, and the output is verified against the authority's own schema.
It is also a demonstration of where AI belongs. The validation is deterministic, because a probabilistic answer to whether a filing is valid is worth nothing.
Ownership
One of my own products. It is licensed and operated rather than transferred; a client's data within it is theirs and can be exported in full on request.
Start with a call
Twenty minutes to work out whether there is something here worth building. If there is not, I will tell you.