Elena V. sends CASE-8842 to reporting. Vyra fills the form from what the platform already holds — the identity onboarding verified, the device fraud insights fingerprinted, the transactions monitoring flagged, the decision the case recorded — and writes a narrative that cites each one, in the schema your FIU expects.
Between 12 and 13 August the subject made seven cash deposits totalling $4.87m across three branches, none above $900kT-4465…4471against a declared monthly turnover of $1.4mKYCThe deposits were made from one device also seen on a second accountDEV-9f21No invoices were produced when asked.
A second subject shares that device. How should she appear?
Nothing appears on the form that is not already in the case.
Vyra writes the first draft and never the last one. Every sentence can be rewritten, every value shows where it came from, and the form cannot leave the building until it passes the schema your FIU publishes.
Illustrative draft
No invoices were produced when asked. The subject is structuring deposits to evade reporting. The deposit pattern is consistent with structuring; the subject gave no commercial explanation when asked on 13 August.
The XML goes to the FIU portal. The PDF goes in the file, page-numbered and signed. The same report answers an API call, so your board pack, your auditor and your internal MI read the filing itself rather than a spreadsheet about it.
All three are rendered from one record, so they cannot disagree
Illustrative
The undersigned has reviewed the report and the evidence attached to it, and files it under FATF Recommendation 20. The narrative, the subjects and the transactions are as held on the entity record at the time of filing.
Trusted by top financial institutions and fintech leaders across the EMEA region
The same report at three points in its life. Assembled from the record that onboarding, fraud insights, monitoring and the case built between them, revised by the person who signs it, and filed with the receipt kept beside the evidence.
The case attaches a device shared with two other accounts. goAML accepts several subjects on one report, and your FIU reads linked subjects as one network rather than three unrelated filings.
The schema version, the agent version and the evidence set are frozen into each draft. A filing from March can be read in March's terms.
Youverify drafts the report, validates it against the published schema and produces the XML. Your team uploads it to the FIU portal under your own credentials and records the acknowledgement back, by API or by hand, so the entity record stays complete.
The rejection and its reason attach to the report. The correction is filed as a new version and the rejected one stays readable, because the question later is not only what you filed but what you filed first.
Three things put a reporting obligation on your desk: an investigation that ends in suspicion, a threshold or a calendar, and a regulator asking a direct question. All three are drafted from the same record and land in the same queue.
An investigation ends in a decision to report. The case already holds the subjects, the transactions, the indicator and the analyst’s reasoning, so the STR is assembled rather than written from memory a week later.
Cash above the reporting threshold, and the returns your regulator expects on a calendar, are assembled from the same transaction record on the schedule the market sets. The queue shows what is due, what is drafted and what has been acknowledged.
A request arrives naming a customer and a date range. Instead of six people searching six systems, Vyra assembles the response pack from the entity record — the verification, the transactions in the window, past filings, the decisions and who made them — and you review it before it goes.
The evidence does not change when you cross a border. The form does. Each market carries its own authority, channel, schema, report types and clock, and a report is drafted against the profile of the market it belongs to — not the one your head office sits in.
Switch the region at the top of this page to read another market's profile. Profiles are configured with your compliance team and reviewed when a regulator republishes.
| Authority | Reports | Channel | Clock |
|---|---|---|---|
| NFIU · Nigeria | STR · CTR | goAML | within 24 hours of suspicion |
| UKFIU · United Kingdom | SAR · DAML | SAR Online | as soon as practicable |
| FinCEN · United States | SAR · CTR | BSA E-Filing | within 30 calendar days |
| FIC · South Africa | STR · CTR | goAML | within 15 business days |
| FRC · Kenya | STR · CTR | goAML | within two days of suspicion |
| CENTIF · Côte d'Ivoire | DOS · DTE | goAML | without delay |
| SAFIU · Saudi Arabia | STR · CTR | goAML | without delay |
Three renderings of one record. The $4.87m in the XML, the $4.87m on page two of the PDF and the $4.87m your MI query returns are the same figure, read from the same place — nobody rekeys it between them.
<report> <report_code>STR</report_code> <entity_reference>CASE-8842</entity_reference> <transaction> <amount_local>4870000</amount_local> </transaction> <indicator>STRUCTURING</indicator></report>Validated against the published schema before it leaves, so a rejection is a surprise rather than a routine.
Page-numbered, signed by the person who filed it, with the evidence index as an annex.
Kept with the case, not on someone's desktop.
GET /v1/reports/STR-2026-0412{ "case": "CASE-8842", "status": "acknowledged", "receipt": "FIU-2026-88431", "amount_local": 4870000, "artifacts": ["xml", "pdf"]}Query by case, entity, date, status or jurisdiction. A webhook fires on every status change — drafted, signed, submitted, acknowledged, rejected.
This is what running fraud and AML on one record buys you at the end of the process. The identity was verified at onboarding. The device was fingerprinted when the session opened. The pattern was caught and scored by a monitoring agent. The decision to report was taken in a case with a named owner. By the time the report is due, almost every field already has an answer — with the date it was captured and the system it came from still attached to it.
Four fields of judgement instead of an afternoon of copying. And because every value keeps its source, the answer to how do you know that is one click away rather than one archaeology project away.
Run one part of the platform or all of it. Vyra asks you for whatever it cannot read, and marks those fields as answered by a person rather than by a record.
No. Vyra drafts from the case file and validates against the schema. A named person reads it, edits it, signs it and submits it. The submission carries their name, not the model’s.
Every word of it. Edits are tracked against the draft version with who made them and when, and Vyra re-checks that each remaining claim still points at a piece of evidence in the case.
Reporting works on its own; it just fills in less. Every field Vyra can read from onboarding, fraud insights, monitoring or the case is populated with its source and date attached. Anything it cannot read it asks you for, and marks as answered by a person. The more of the record you run in one place, the fewer of those there are.
XML in the schema your FIU publishes, a page-numbered PDF with the evidence index as an annex, and JSON over the API. The three are generated from the same record, so they cannot disagree.
By report id, or by query on case, entity, date, status or jurisdiction. The response carries the filing, its acknowledgement and links to both artefacts. A webhook fires on every status change.
The rejection and its reason attach to the report. The correction becomes a new version; the rejected version stays readable. Both are on the entity record when someone asks what happened.
Schema versions are maintained per market and validation runs against the current published one. Reports already filed keep the version they were filed under, so an old filing still reads correctly.
Yes. A case with several subjects can be filed as one report with multiple subjects or as one report each, and a case touching two markets produces one report per authority, each in its own schema.
No, and it does not claim to. Youverify drafts the report, validates it against the schema the regulator publishes and produces the XML their portal accepts. Your team uploads it under your own credentials and records the acknowledgement back, by API or by hand, so the entity record stays complete.
Vyra drafts them. It reads the case, the entity record, the monitoring alerts and the fraud signals, fills the fields the schema requires and writes the narrative with each claim pointing at a piece of evidence. Threshold reports like CTRs are assembled on a schedule from transaction data with no case behind them. A named person still reads, edits and signs before anything leaves.
Yes. For markets that file through goAML — Nigeria, Kenya, South Africa, Côte d’Ivoire and Saudi Arabia among them — reports are generated as goAML XML and validated against the schema version the FIU currently publishes. Markets on their own formats, such as the United Kingdom and the United States, are generated in theirs.
The record is already there: the identity from onboarding, the device and behavioural signals from fraud insights, the flagged pattern from monitoring, the decision from the case. Vyra maps that record onto the fields your regulator’s schema asks for and drafts the narrative. Your MLRO revises and signs. The platform then produces the validated XML, the PDF for the file and the API record.
Software that turns what a compliance team already knows into the filings its regulator requires — suspicious transaction and activity reports, threshold and currency reports, and answers to information requests — in the schema, channel and deadline that regulator publishes, with a record of who filed what and on what evidence.
Reporting profiles are configured for Nigeria, the United Kingdom, the United States, South Africa, Kenya, Côte d’Ivoire and Saudi Arabia. A profile carries the authority, the channel, the schema, the report types, the statutory clock and the legal basis for that market, and is reviewed with your compliance team when the regulator republishes.
A filing is not a document assembled at the end. It is the same entity record, read out in the form your regulator publishes.
Bring us one closed case. We will show you how much of the form your own record already answers, draft the STR in front of you, validate it against the schema your FIU publishes, and hand you the XML, the PDF and the API call that reads it back.
Youverify holds SOC 2 Type II, ISO 27001, ISO 27018 and ISO 42001 certifications, and is registered with the data protection authorities in Nigeria, Kenya, South Africa, Côte d’Ivoire and the United Kingdom.
