Reads what the bank actually produces rather than requiring a new export.
CTR to goAML Conversion
A compliance team spent hours a week turning Currency Transaction Reports into goAML XML by hand. Parser, XML builder, schema validator and audit trail, behind an interface officers actually use.
The problem
What it was like before
goAML takes XML in a prescribed schema. The data starts as reports the bank already holds in a different shape. Between the two sat a person, a spreadsheet and a considerable amount of care.
Hand-built XML fails in the least useful way: the submission is rejected, the error names a schema rule rather than a business problem, and somebody works backwards from a validation code to a missing field.
How it looks
Where a submission goes
Validation sits before submission, so a failure is fixed rather than discovered after rejection.
What we built
What it does
Constructs submissions to the prescribed structure rather than assembling them by hand.
Files are checked against the schema before they are sent, so errors are found while they are still cheap.
What was converted, when, from what, and what came back.
Officers use it themselves. A conversion tool only one engineer can run has not removed the bottleneck, it has moved it.
The format has been revised repeatedly; the pipeline was written expecting that.
Where it got to
In production
v5.0.2goAML schema
FirstSubmission accepted
ThreeFormat migrations survived
Our view
The schema will change again
Regulatory formats are revised, and each revision breaks something written against the last one. This pipeline has survived three migrations, which is the only real evidence that it was built for the job rather than for the deadline.
We write more about this in the pieces on goAML filing and on what a reporting deadline of 'promptly' actually asks a bank to evidence.
Built with
Tech stack
- Python
- Flask
- lxml
- openpyxl
- SQL Server
- pytest
The work behind it
Delivered under Compliance & RegTech Automation and Custom Software Development.
More work
Other things we have built.
Sanctions Screening Agent
Watchlist alerts arrive all day and most are false matches. The agent clears the obvious ones against a rule engine backed by an LLM and sends every disagreement to a person with the evidence already assembled.
Read itLaw-Enforcement Request Intake
Requests arrive as letters with scanned attachments. The agent reads the mailbox, OCRs the attachments, verifies identifiers against core banking, classifies the intent and routes it — with an audit trail behind every step.
Read itInternal Policy Assistant
Staff ask a policy question in plain language and get an answer drawn strictly from approved documents, with the source named. Nothing leaves the bank, and the assistant says so when the documents do not answer.
Read itRegulatory Reporting Engine
A registry of every periodic return a bank owes. The engine pulls the data, builds each report against the mandated template, then schedules and submits it behind a maker-checker step.
Read itAutonomous Social Media Agent
A ReAct loop that researches, reads its own history to avoid repeating itself, writes a strategy memo, critiques its own drafts, publishes, and learns from every rejection.
Read itMulti-Agent Marketing System
Two agents on one platform with a person approving everything before it ships. One researches and takes a position; the other plans a week of posts reviewed as a batch.
Read itWhatsApp Booking Agent
Patients book on the number a clinic already advertises, at any hour, in the language they normally write. Only genuinely free slots are offered, and anything clinical goes to a person immediately.
Read itHave something like this?
Describe the process and we will come back with whether it is worth automating, roughly what it would take, and what we would build first — or tell you plainly if it is not a job for us.