SEPRELAD and AML
Veridia is not certified, registered, approved, or reviewed by SEPRELAD or by any other financial-intelligence unit. It generates no regulatory report, produces no filing in any supervisor's format, and submits nothing to anyone on your behalf.
If you are an obligated subject, your AML obligations remain entirely yours: your programme, your compliance officer, your risk assessment, your filings. What this page describes is a set of controls that can contribute evidence to that programme — not a substitute for it.
Confirm with counsel what your regulated activity actually requires. This page cannot tell you.
With that boundary stated, here is precisely what the system does.
Sanctions screening
Every verification whose OCR produced a name is screened against sanctions lists before a verdict is issued.
Which lists
| Source | List |
|---|---|
| OFAC (US Treasury) | Specially Designated Nationals (SDN) |
| United Nations | Consolidated Sanctions List |
That is the complete coverage. Specifically not included:
- No PEP list. Politically exposed persons are not screened at all.
- No adverse-media screening.
- No EU consolidated list. Considered and deferred; not implemented.
- No local or regional lists of any jurisdiction.
If your programme requires PEP screening — and for many regulated activities it does — you need a separate provider or process for it. Do not assume it is covered here.
How current the lists are
A timer refreshes both sources daily from the publishers' official endpoints and rebuilds the matching index. If a download fails, the previous index stays in place rather than the system falling back to screening against nothing.
The dated state of the lists is therefore "yesterday's publication at worst" under normal operation — but there is no alerting contract around a persistently failing refresh, and no published freshness SLA. If list currency is an audit point for you, verify it operationally rather than assuming it.
What a match produces
Screening results surface as flags on the verification:
| Flag | Level | Meaning |
|---|---|---|
aml_sanctions_match | err | A strong match against a listed name |
aml_possible_match | warn | A weaker match worth human attention |
A strong match forces the verification to review, so that a person decides. It does not produce a rejected verdict on its own, no matter how confident the match.
This is deliberate and worth understanding, because the intuitive design is the opposite. Name matching against sanctions lists produces false positives constantly — common names, transliteration variants, partial matches. Auto-rejecting on a name match would deny service to real people on the strength of a string comparison, and would do it silently. Forcing the case in front of a human is the only defensible handling: the decision, and the reasoning behind it, then belongs to a person who can be asked to justify it.
The consequence for your integration: a sanctions case arrives as verdict: "review", not as a rejection. If your onboarding treats review as a queue nobody watches, sanctions cases sit in it.
A limit worth knowing
Screening runs on the name extracted by OCR from the document. If OCR misreads the name, screening runs against the misread version. A name that fails to extract is not screened at all.
This is inherent to screening a photographed document rather than a typed-in identity, and it is not fully closed by anything in the pipeline. If you need the screened name to match a name your own systems hold, send it as submittedFullName at init so that the comparison between the two is scored and visible in the results.
What the system retains as evidence
The verification record is designed to survive as the artefact of the identity check. It holds:
- The verdict, the overall confidence, and each individual check's score
- Every flag raised, including the sanctions flags above
- The identity fields extracted from the document
- Submission and completion timestamps
- Where a person reviewed the case: who reviewed it, when, and their note
Records for verifications identified as Paraguayan keep their images for 5 years; everything else, and anything whose jurisdiction is uncertain, for 8. The database row itself is never deleted by the retention sweep. See Data retention for exactly what that means, including the part where the images go and the record stays.
What Veridia does not produce
Listed explicitly, because these are the things an AML programme needs and would be reasonable to assume a "KYC/AML" product provides:
| Suspicious activity reports (ROS / STR) | Not generated, not formatted, not filed |
| SEPRELAD reporting formats | Not implemented |
| Filing or submission to any supervisor | None |
| Customer risk scoring or rating | Not produced. The confidence score is an identity-verification measure, not a money-laundering risk rating — do not use it as one |
| Ongoing or periodic re-screening | Not implemented. Screening happens once, at verification. A customer who is listed after they were verified is not re-screened and will not be flagged |
| Transaction monitoring | Out of scope entirely |
| PEP or adverse-media screening | Not implemented |
| Beneficial-ownership or corporate KYB | Not implemented |
| Record-keeping in any supervisor's prescribed format | Not implemented |
The absence of ongoing re-screening deserves particular attention. Lists change; a one-time check at onboarding is a point-in-time control. If your obligations include periodic re-screening of your existing customer base, that has to be solved elsewhere.
What you can reasonably say
If you are describing your stack in your own compliance documentation, the defensible statements are of this shape:
Identity verification is performed by a third-party provider, which screens the extracted name against the OFAC SDN and UN Consolidated lists at the time of verification. Strong matches are routed to manual review rather than automatically rejected. Verification records, including the verdict, the checks performed, and the reviewer's decision, are retained for [period].
What is not defensible is any statement implying Veridia is SEPRELAD-certified, that it discharges a reporting obligation, or that using it makes an onboarding process compliant. It does not, and asserting so in a document a regulator may read creates a problem considerably larger than the one it solves.