A compliance officer in Singapore types one sentence: catch customers breaking large cash deposits into pieces that sit just under the bank’s own review threshold. No query language. No ticket to engineering.
Over what window should the deposits count as one burst? Pick one, or type your own.
Or start from a template the library shows what each one produced on your own traffic.
Vyra receives each live event, evaluates the whole workflow, then stops before the action node. No case is opened, no notification is sent, no customer is affected. The evaluation path is identical to production, so what you are reading is what production would have done.
Across the first nine days, 14,208 transactions, this version would have raised 96 would-be alerts about 0.7% of volume. The number will move as more traffic arrives. Do not act on it yet.
Two separate measurements, kept apart on purpose. Do not blend them into one figure when you report it.
A hit holds the transaction, opens a case on the entity and attaches everything it read: the conditions, the values, the screening result. Elena V. decides, and the decision lands in the format your FIU expects.
Trusted by top financial institutions and fintech leaders across the EMEA region
The same agent, at three points in its life. Built in the workspace your analysts already use, proven against your own history, and answerable for every case it opens.
Add a condition for deposits made across three or more branches in the same window. On your last ninety days it separates genuine traders from the pattern you are describing.
Every version keeps the traffic it was tested against. When a regulator asks why an agent behaved a certain way in March, you open the version that was live in March.
Seven deposits across three branches, none above $900k, together $4.87m against a declared turnover of $1.4m a month. No matching invoices on file. Recommend EDD and a draft STR.
The same endpoint carries every event at every stage. Shadow, rollout and live differ by one header value, so you wire it up once and change your mind as often as you need to. Auto-rollback stays armed in production though anything done before a rollback stays done.
POST /v1/agents/{agent}/evaluateX-Vyra-Mode: shadow"event_id": "TXN-8841027","entity": { "account_id": "ACC-4471" },"transaction": { "amount": 28000, "currency": "USD", "direction": "outbound" }A template that has run here carries the numbers it produced on your settled traffic, and the library is ranked by how well each one backtested in your data. The ones that have never run on it say so, instead of borrowing someone else’s figures.
Or describe one that is not in the library. That is what Vyra is for.
Every agent that fires opens a case on the entity it fired against the same entity record onboarding built. The transactions, the customer's declared profile, the earlier alerts and Vyra's reasoning are already attached when your analyst opens it.
Vyra investigates. Your workflow decides.
| Case | Severity | SLA |
|---|---|---|
| Structuring · deposits under thresholdCASE-8842 · Amara C. | High | 4h left |
| Funds in and straight out · 11 accountsCASE-8836 · Lucas Moreau | High | 19h |
| Cross-border volume above profileCASE-8829 · Meridian Logistics | Medium | 2d |
| Dormant account, sudden throughputCASE-8817 · Sofia Rossi | Low | 3d |
A payment business reaches its payers through merchants, so what it knows about them is thin: an email, a company name, an account. The device that sent the payment is the part nobody can type in.
Fraud-insights signals arrive with the payment, read by the SDK at checkout or passed to us in the payload. They resolve into one payer profile that sharpens every time that payer comes back.
So you can know this device has been behind chargebacks before, on merchants with nothing to do with each other, from a payer whose name you were never able to verify.
The email and company name are used as links between sessions, never as facts.
The beneficiary is screened as its own counterparty. This one has received from nine sub-merchants this month, none of them related on paper.
On the payer, and on the beneficiary when the money moves on. Which run, and what a hit does, is whatever your workflow says.
Loaded alongside, read as one more condition — at sub-merchant onboarding and on every payment after.
A pattern only looks wrong against something. For a bank that is the customer’s declared profile. For a payment business it is the merchant’s the corridor, the ticket size and the history of the merchant you did onboard. Either way it came from onboarding, the device that opened the session came from fraud insights, and the case an agent opens sits on the same record as both.
It is the same kind of logic, written a different way. You describe the pattern in a sentence; Vyra assembles the conditions, the action and the alert from your variable library, and you read every line before it runs. What changes is the time between noticing a typology and having it live and that the reasoning is on the record.
No. The backtest is a gate: nothing can be deployed until it passes on your settled traffic. Shadow mode is then optional it evaluates live events and suppresses every action it would have taken, for as long as you want that evidence. Going to production is an explicit choice with its consequence written beside it, and the version history keeps who chose what and why.
Alerts are scored, not stacked, and one customer in one window raises one alert rather than one per transaction. Before you turn an agent on you see what it produced on your settled traffic. Precision confirmed by analyst dispositions is reported separately from precision estimated on alerts nobody has reviewed the two are never blended into a single figure.
Yes. Conditions are assembled from named variables deposit counts, cumulative amounts, ratios against a declared profile with operators and windows you set in the panel. Vyra proposes; you edit, add and remove by hand at any point.
Integration is by API and typically takes days, not quarters, with the transaction schema mapped onto the variables your agents read. Existing rules can be imported and backtested alongside the new ones.
For every alert: the agent version that fired, the conditions it evaluated, the values it read, the case it opened, who worked it, what they decided and when. The version live at the time is kept, so a decision from March can be explained in March’s terms.
One entity record. A pattern is scored against a profile onboarding verified the customer’s at a bank, the merchant’s at a payment business and the device that opened the session comes from fraud insights. Counterparties nobody onboarded are screened rather than profiled, on the same record and into the same case queue.
As long as you want. There is no fixed end date it runs until you stop it, the estimate tightens with every day of traffic, and shadow evaluation is metered while it runs. Early numbers are labelled provisional and directional, because on a few days of data that is all they are.
Yes, by screening rather than profiling. A payment message carries a counterparty name, an account, a bank, a corridor, an amount and a card BIN, and that is screened against sanctions, watchlists, PEP and adverse media, corridor and beneficiary-bank risk, VASP exposure and issuer geography. The payment is then measured against the merchant you did onboard, against what that counterparty has done across your traffic before, and against everything else moving through that merchant in the same window.
Yes. STRs and returns are drafted from the case file in the schema your regulator expects, and agents can be scoped per market so a threshold in one country does not follow you into another.
A monitoring alert does not become another silo. It stays on the same entity record used across onboarding, investigation and reporting.
Bring us ninety days of transactions. We will build an agent from one sentence in front of you, replay it over your own history, and show you what it would have caught.
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.
