veilnebu.la does not verify anyone’s identity. It does screen blockchain addresses against sanctions data. Those are different controls answering different questions, and this page sets out exactly which one runs where — including the places where nothing runs at all.
1. No identity verification, anywhere
There is no customer-identification programme, no document upload, no selfie or liveness check, no proof of address, no source-of-funds questionnaire, and no company-registration review. A merchant account can be opened with no email and no password. The identity-verification module that once existed was removed rather than left dormant, because a half-wired verification step implies a check that never actually runs.
We therefore hold no identity data to screen, and we do not run PEP screening, adverse-media screening, or name and entity screening. We could not: there is no name.
2. What is screened, and where
Screening operates on a single input — a blockchain address, with its network — and is applied at two points only.
Payout and refund destinations: a hard block. Before a payout or a refund is created, the destination address is screened. If the result is a sanctions match or a high-risk score, the request is rejected and no transfer record is created. Batch payouts are screened item by item, so one rejected destination does not stop the rest of the batch. This is the control that stops the operator from settling to a designated address, and it is the reason screening survived the decision to drop identity checks.
Incoming payments: advisory only. A deposit that is detected on chain is credited first and screened afterwards, out of band. A flagged result raises a payment.risk_flagged webhook to the merchant. Nothing is frozen, held, or reversed automatically.
There is an honest limit here that we would rather state than let you assume around: the chain watcher receives the deposit address we generated, not the payer’s source address. Inbound screening therefore does not assess the counterparty who paid you. Do not treat an unflagged incoming payment as a screened one.
Nothing else is screened. Invoice creation, hosted checkout, settlement, treasury sweeps, internal transfers and swaps have no screening step.
3. What the screening runs against
- A committed sanctions address list. A small set of OFAC-designated crypto addresses — mixer and DPRK-attributed clusters — held in the repository and updated by code change. It is a targeted list, not a full SDN ingest.
- An operator-configured refresh source, merged into that list when the operator points it at one. Refresh is triggered by an administrator; there is no automatic daily update job.
- A third-party KYT provider, where the operator has configured one. Integrations exist for AMLBot and Chainalysis and are enabled by API key. No other vendor is integrated.
We do not maintain or ingest EU, UN, or UK/OFSI consolidated lists. Where several sources disagree, the strictest result wins and the address takes the highest score returned.
4. What the configuration actually is matters
Which of the above is live depends on how this instance is configured, so the accurate statement is conditional rather than absolute. Where no KYT provider key is set, the sanctions address list is the only substantive check that runs, and a placeholder scorer stands in for the absent provider so the code path stays exercised. That placeholder is deterministic but arbitrary; it is not a risk assessment and must not be read as one.
The practical consequence: a payout can be refused to an address you have good reason to believe is clean. If that happens, write to [email protected] and it will be looked at by a person. An administrator can override a screening result, and every override must carry a written reason that is stored with the record.
5. What we do not run
Stated explicitly, because absence is the thing a policy page usually hides behind passive voice:
- No transaction-monitoring rules engine — no velocity, structuring, or typology detection.
- No screening of the payer’s source address on incoming payments.
- No PEP, adverse-media, name or entity screening.
- No ongoing rescreening of addresses already used.
- No automated filing to any financial-intelligence unit.
- No Travel Rule messaging between VASPs.
6. Suspicious activity
An internal suspicious-activity register exists. It is administrator-only — merchants cannot file into it, list it, or see it — and every entry is raised by hand; nothing in the screening pipeline creates one automatically. Entries move through open, under review, and then filed or dismissed, and each transition is written to the audit log.
“Filed” is an internal status. Any report to a regulator or financial-intelligence unit is a manual act by the operator; there is no automated transmission to FinCEN, goAML, or any equivalent. Where the operator is legally obliged to report, it will, and it may be prohibited by law from telling you that it did.
7. Travel Rule
Where originator and beneficiary information is required for a transfer, the operator can record it — names, addresses, account references, the counterparty VASP identifier, and the amount. Collection is manual and administrative.
There is no automated threshold check and no VASP-to-VASP messaging protocol implemented. If your own obligations require you to send or receive Travel Rule data, you cannot discharge them through this Service today.
8. Jurisdictions
Use from comprehensively sanctioned jurisdictions is prohibited under the acceptable-use policy, which is a contractual restriction. It is enforced by the sanctions screening on addresses and by termination, not by IP geolocation: we do not currently block by country, and you should not infer that reaching this Service from somewhere means you are permitted to use it from there.
9. Records
Every screening result is stored with its subject, network, status, score and reasons, and repeated screening of the same address inside a short window reuses the stored result rather than re-querying. Administrative actions — screening overrides, suspicious-activity transitions, exports — are written to an append-only audit log that is hash-chained entry to entry and anchored daily.
Two qualifications. Append-only is enforced by the application, not by a database constraint. And no automatic purge is configured for screening or compliance records, so in practice they are retained indefinitely rather than for a fixed term; the Privacy Policy states this the same way.
10. Screening an address yourself
Merchants can screen an address before paying it, using POST /v1/aml/check with a project API key. It returns a risk level, a score, and a fixed vocabulary of flags — never the raw provider response or the provider’s name. It is rate-limited per key. A clean result is not a warranty, and it does not transfer any obligation of yours to us.
11. Your obligations are still yours
Not being asked for identity documents is not a determination that you owe none. If your activity requires you to run a customer-identification programme, register as a money-services business or VASP, obtain authorisation, or report to a supervisor, that obligation is unaffected by anything on this page and is not discharged by our screening. See Terms §5.
12. Contact
Compliance correspondence, including law-enforcement requests: [email protected]. Registrations and authorisations held by the operator: None held.