Trust & Data

Patterns, not contents.

Settlement instructions are some of the most sensitive operational documents a firm handles. We treat them that way. The instruction text you submit is processed in-memory and never stored. What we keep are anonymized scoring patterns — and we keep them for a reason.

In plain English

What we keep. What we don’t.

The same data policy applies to the free public verifier and paid platform tiers.

The instruction text you paste or upload
Not stored
Beneficiary names
Not stored
Account numbers, IBANs
Not stored
BICs, ABA numbers, sort codes, routing identifiers
Not stored
Counterparty information of any kind
Not stored
Reference numbers, invoice numbers, remittance text
Not stored
Anonymized disposition outcomes (STP, REVIEW, REJECT)
Yes — anonymized
Anonymized rule trigger patterns (which rule IDs fired)
Yes — anonymized
Currency, corridor, and field-shape patterns (no values)
Yes — anonymized
Component scores (Routing Confidence, ISO Readiness)
Yes — anonymized
The distinction that matters

We learn from patterns. Never from contents.

The difference is everything. We retain that an EUR-to-USD wire was scored REVIEW because rule EXT-07-PAR fired — we do not retain who the beneficiary was, what the account number looked like, or which counterparty the instruction came from. That information is processed in memory and discarded the moment the response is returned.

What we do keep is operational signal. Aggregated across thousands of submissions, that signal is what makes the engine sharper, the rule set more accurate, and the resulting industry research valuable to everyone in payment operations.

Why we keep what we keep

The data we retain serves three purposes.

01 — Engine improvement

Sharper rules over time

Anonymized rule trigger patterns tell us which rules fire frequently, which fire rarely, and where edge cases cluster. That feedback loop is how the rule set evolves from 55+ today to broader corridor coverage tomorrow.

02 — Industry research

Insights worth publishing

Aggregate patterns across the industry — disposition rates by corridor, top failure modes, ISO 20022 readiness benchmarks — become research everyone in payment ops benefits from. Submitted instructions help build that view.

03 — Operational quality

System reliability

Latency metrics, error rates, and request-shape data let us monitor the platform’s health and resolve issues before they affect users. None of it requires storing instruction content.

How processing actually works

Paste → Score → Discard.

The instruction text never touches a database. The pattern of what happened — anonymized — is what persists.

📋

You paste

The instruction text enters memory in your browser session, then transits to the scoring engine. It is never written to persistent storage.

⚙️

We score

The extraction and scoring engine produces a result. The instruction content is held only as long as needed to compute the response.

🗑️

Content discarded

Once the response is returned, the instruction text is discarded. Only the anonymized pattern of the result is retained.

For institutional clients

Audit, hosting, and contractual data terms.

Institutional clients on subscription tiers get explicit data processing agreements, configurable retention windows for audit and recordkeeping compliance, dedicated environments where required, and SOC-compatible operational logging that excludes instruction content.

If your compliance team needs to review our architecture, hosting model, or data flows in detail — that’s a conversation we welcome. Reach out.

Try it. Then verify it.

The verifier is open. Use the developer tools to confirm what we say is true — there’s nothing to hide.