Governed reporting
A filing you can explain field by field, and prove you delivered
Every value in a generated report carries the expression that produced it and the evidence it came from. The document is stored as the exact bytes that would be transmitted, with its digest. Approval is four-eyes. And a report becomes submitted only when an external filing reference is recorded against that exact payload.
The platform generates, validates, approves and records. It does not transmit. Filing happens through the institution's authorised external channel, and what Baobyte holds is the evidence of it — which is the honest description of what is built.
The problem
Three ways a filing goes wrong, and none of them look wrong at the time
Regulatory reporting is where every upstream compromise becomes visible — usually to somebody else, usually late.
Numbers that were retyped
A narrative assembled by hand from a spreadsheet is a transcription exercise. The figures in the return and the figures in the case evidence drift, and the institution cannot say which one is right without redoing the work.A submission nobody can evidence
The report is marked filed in one system and delivered through another. Months later there is a status flag, no receipt, no reference, and no way to show the bytes that were actually sent matched the bytes that were approved.A format that was assumed
A schema copied from a sample or reconstructed from a PDF looks exactly like an authoritative one on screen. It validates, it renders, and it is rejected — or worse, accepted and wrong.
How it works
Generate from evidence, validate against a registered schema, record the delivery
Five report kinds are projected: suspicious transaction reports, currency transaction reports, SCUML returns, CBN returns and internal board packs. The first four are regulatory; the last one is explicitly not, and the product says so on the screen.
Compliance administrator
Register the schema, then map the fields to it
A schema version is registered with its format and its provenance, and marked authoritative only when it carries a real compiled validator and named regulator provenance — a non-XML schema claiming to be authoritative fails closed, and an authoritative registration without an XSD is refused. Field mappings are expressions over the canonical model, validated for target path, required-ness and expression correctness before they can be proposed, with tenant overrides preserved across content-pack updates.Analyst or MLRO
Generate from an evidence set, not from a form
A report is drafted from what is linked: the case and its alerts, the transactions that evidence reached, the customer and its CDD context. The narrative defaults to the case summary and is edited rather than composed from nothing. Generation is idempotent from a source event, so the same trigger produces the same report identity rather than a second copy. Currency threshold reports can also be generated automatically from monitored transactions, under the same gates as any other report.Platform
Every field records the expression that produced it
The report screen lists each field, the expression over the canonical model that produced it, the value it produced and whether the authority requires it. Without those traces the contents of a filing cannot be explained, which makes it unfit to sign — so their absence is presented as a defect rather than as an empty panel.Platform
Validation is named, and its limits are named with it
The validator that passed the document is displayed by name alongside the result. Where the check was structural rather than schema-based, the screen says exactly that: well-formedness, required fields and unknown elements only — cardinality, code lists and data types unverified. A failed validation stores the document with its errors rather than discarding it, because a failure you cannot inspect is a failure you cannot fix.MLRO
Review, then approval by someone who did not generate it
A report moves from draft to review to approved. The screen warns the generator when they are looking at their own report, and the report identity, payload, field traces and external evidence are immutable throughout. Report summaries deliberately do not disclose customer or content identifiers: reading the register and reading the filing are separate permissions.MLRO
Export the exact bytes and file them through your own channel
The stored document is the bytes as they would be transmitted, byte for byte, and can be downloaded as such or printed with a masthead and a repeated footer carrying the reference and the filing status. Filing itself happens through the institution’s authorised external channel. The screen states that plainly above the control: recording evidence is not transmission.MLRO
Record the delivery evidence, and later the regulator's answer
Submission requires the external filing reference actually returned by the channel and the time it was filed, and binds them to the payload digest and the schema digest. Only then does the report read as submitted. An acknowledgement or a rejection is attached afterwards to the same immutable history — a rejection carries the regulator’s stated reason and the report is corrected by a new version rather than by editing the one that was sent.
In the product
The report detail screen
One page holds the document, the proof, the provenance and the disposition — and prints as a defensible artefact rather than as a screenshot of a web page.
Placeholder — TODO: capture the report detail screen (/reports/{id}) from a seeded demonstration tenant — no screenshot of it exists yet. Replace with sourced, approved content before this page is made public.
/reports/{id}report detail
Screenshot slot. Capture from a seeded demonstration tenant with synthetic data and replace this frame. Do not substitute a mock-up of the interface.
What the capture must show
- Schema status, stated firstA report generated against a placeholder schema carries a standing refusal explaining that submission is blocked by the API, by the service and by a database constraint.
- Validation panelThe validator named, the result, and where the check was structural rather than schema-based, exactly which properties remain unverified.
- Field provenanceEvery field with its source expression, the value it produced, and whether the authority requires it.
- The document itselfThe exact bytes as they would be transmitted, scrollable on screen, downloadable, and printable without silent truncation.
- Filing evidenceExternal reference, actual filing time, payload digest, schema digest, who recorded it and when — with acknowledgement or rejection attached afterwards.
- Deadline stateWhether the filing deadline was met or breached, with the due and met timestamps beside it.
Controls
What makes a filing defensible
Six properties, each of which an examiner can test directly against the record rather than against an assurance.
Field-level traces on every value
The expression, the source records and the policy version behind each field are stored with the report. That is what turns “where did this figure come from” from a research project into a lookup.Digest-bound delivery evidence
The payload digest and the schema digest are recorded with the external reference and the actual filing time. A submitted state without matching external evidence is not reachable.A non-authoritative schema cannot be filed
Submission is refused for a report generated against a schema that is not marked authoritative, and the refusal is implemented three times over — in the handler, in the service and in a database constraint — rather than in the button that is disabled.Mixed currency is refused, not summed
A report cannot silently aggregate amounts across currencies. Where the evidence set is mixed, generation refuses or produces approved separate totals — it never produces a single misleading number that looks like a threshold breach.Deadlines are computed and recorded
The filing window for a report kind is tracked, and whether it was met or breached is part of the record rather than something reconstructed from timestamps afterwards.The printed artefact carries its own status
Print output repeats the reference and the filing status on every page, and a placeholder-schema warning is deliberately not hidden from print — a warning that vanishes when the page is printed is a warning that fails in exactly the situation it exists for.
Where the edges are
The engine is built. The regulator's artifacts are yours to supply.
This is the capability where the gap between an engine and an accepted control is widest, and where a vendor claiming readiness would be most expensive to believe.
In the product today
- Projection of five report kinds — suspicious transaction reports, currency transaction reports, SCUML returns, CBN returns and internal board packs — from governed mappings with retained schema, pack and configuration provenance.
- Deterministic rendering to exact bytes with a document digest, a named validator, stored validation errors and a field-level trace for every value.
- Draft, review, four-eyes approval, immutable payload and traces, and register metadata kept separate from filing content by permission.
- Digest-bound external filing evidence, with acknowledgement and rejection attached idempotently to the same immutable history, and computed filing deadlines.
- Scheduled internal board packs with layout snapshots, recurrence across time zones and daylight saving, deterministic occurrence identity, artifact digests and an append-only run ledger.
Not claimed here
- The authoritative NFIU goAML schema, its code lists and the approved mapping interpretation. The schemas shipped with the build are placeholders and are marked as such; a report generated against one cannot be submitted.
- Any transmission to a regulator. There is no filing transport and none is claimed. The platform records evidence of a filing performed through the institution's own authorised channel.
- Correction and re-submission semantics as the authority defines them. A rejected report is corrected by a new version here; whether that satisfies the regulator's correction procedure is a question for the filing UAT.
- Board packs as a regulatory output. They are internal aggregate distribution, they exclude customer names, they keep small cells suppressed and unavailable metric streams unavailable, and they cannot create, submit or acknowledge any regulatory filing.
- Email delivery of a board pack where the installation has no mail relay configured. The run ledger records the refusal explicitly rather than reporting a delivery that did not happen.
Keep reading
Related capabilities
Where the evidence comes from, how the filing record is retained, and what the filing acceptance work actually involves.
Bring your reporting obligations
We will map one of your returns against the engine
Bring the artifact you file today. We will walk the mapping record it would need — authority, schema version, code lists, transformations, requiredness, evidence and filing channel — and tell you honestly which parts are configuration and which are still open.