A customer passes onboarding, then requests a withdrawal to a new address. Your team needs to know which parties and identifiers were checked, what each result means and who can decide whether the transfer proceeds. A single label such as “wallet screened” leaves too much of that work unexplained.
This guide helps virtual asset service providers (VASPs), crypto-asset service providers (CASPs) and crypto-enabled payment businesses connect customer screening, wallet-address checks and transfer review. The workflow is an operational recommendation to adapt to your services, jurisdictions and policy. It is not a universal legal checklist.
Give each control a clear question
The most useful starting point is a map of what your controls actually answer. Several services may contribute to one onboarding or transfer decision.
| Control | Question it helps answer | Boundary to preserve |
|---|---|---|
| Customer and entity sanctions screening | Does supplied identity information produce a candidate against relevant sanctions data? | A candidate requires review; absence of a name match does not resolve ownership, control or every applicable restriction. |
| PEP screening | Does a person have relevant political-exposure information? | PEP status is a due-diligence consideration, not a sanctions designation or finding of wrongdoing. |
| Wallet-address sanctions check | Does a supplied address produce a candidate against supported sanctions identifiers? | It does not establish wallet ownership, transaction history or indirect exposure. |
| Blockchain analytics or KYT | What does on-chain activity, attribution or exposure analysis indicate? | This needs a separate capability and a clear explanation of its coverage and methods. |
| Travel Rule process | Is the required originator and beneficiary information collected, checked and exchanged for transfers in scope? | Screening the parties does not perform the information exchange. |
| Behavioural transaction monitoring | Does activity warrant investigation in its customer and transaction context? | Screening names and identifiers does not analyse patterns of behaviour. |
Keep the Crypto AML and Travel Rule resource hub as the broader starting point. For the generic control distinction, see transaction screening versus transaction monitoring.
Define subjects and data before choosing the screening event
For each service—account opening, corporate onboarding, deposit, withdrawal or transfer—record which subjects enter scope and where their information comes from. A person, a corporate customer, a beneficiary and a wallet address should not become an undifferentiated search term.
Record the relationship between the customer and each supplied party. For a business account, this may include already-identified beneficial owners, controllers or authorised representatives where required by policy. Screening those supplied parties does not discover the ownership structure. Use the UBO and related-party screening guide for that separate workflow.
Retain the source and freshness of identifying information. Names, aliases and available secondary identifiers help reviewers distinguish people or entities with similar names. Avoid filling gaps with guesses, and do not treat missing data as evidence that a candidate is unrelated.
Wallet addresses need their own input field and transaction context. Preserve the supplied value and network information where available. Decide how unsupported or incomplete input is handled before a live customer reaches that path.
At onboarding: resolve the customer context
Screen the customer or company and the other parties your policy places in scope. Keep sanctions results, PEP information and adverse-media findings distinguishable: they answer different questions and can lead to different review actions.
Identity verification and company verification belong to the wider onboarding process. A screening result does not prove that the applicant is the person named, that a company record is authentic or that an applicant controls a wallet.
Give each potential match a reviewer and record the facts used to resolve it. When a corporate relationship raises an ownership or control question, route it to the appropriate analysis even if no direct name match was found. For the legal perimeter, use the practical sanctions screening guide.
If ambiguous names create repeated work, use the existing false-positive reduction guide to design and test calibration. If media reporting needs investigation, use the adverse-media review and documentation method. Neither process should be reduced to an automatic rejection rule.
Around a transfer: connect the result to the event
Define the checkpoint at which screening informs the transfer workflow. A withdrawal request may introduce a new beneficiary, counterparty or destination address; an earlier customer check cannot show that those new inputs were screened.
An illustrative withdrawal review might proceed as follows:
- Capture the customer reference, transfer reference, relevant supplied parties and destination address.
- Run the checks required for those subjects using the selected configuration.
- Distinguish completed checks, candidates requiring review and technical or data failures.
- Apply the firm's review and escalation procedure, alongside any other required controls.
- Retain the screening execution and the authorised operational decision under the transfer record.
These stages describe responsibilities, not a universal rule to hold or release funds. The applicable requirements and your firm's authorised decision process determine the response.
Checklynx's documented POST /transactions workflow keeps supplied parties within a transaction-screening run. Its wallet_address payment instrument checks the supplied address when the chosen profile enables sanctions identity screening. Store the returned run ID alongside your own transfer reference so the execution can be retrieved. The developer documentation defines the supported fields and current behaviour.
If your platform owns the entire review record and only needs direct checks, another integration model may fit better. The Transaction Screening API versus Sanctions & PEP API guide covers that decision, correlation and retry handling without duplicating them here.
What a wallet-address result can tell you
For US sanctions, OFAC FAQ 562 explains that the agency may publish digital-currency addresses associated with blocked persons and that those listings are unlikely to be exhaustive. A search against published identifiers therefore cannot establish that every address associated with a sanctioned person has been checked.
A direct address candidate and indirect exposure through other addresses are different findings. Investigating transaction paths, attributing wallets, identifying clusters or analysing indirect exposure requires capabilities beyond sanctions-identifier screening. Assess separately whether your risk assessment calls for a blockchain-intelligence provider or other investigation tools.
Record a no-candidate result in terms of the check performed: the supplied address, relevant screening configuration, time and returned result. Avoid converting it into “safe wallet”, “verified owner” or “no crypto risk”. The customer, counterparty, ownership and wider transfer context may still require work.
Use Travel Rule information without confusing the controls
Originator and beneficiary information can help populate the party records used in screening. Assign an owner for receiving that information, resolving inconsistencies and keeping the screening inputs connected to the transfer.
In the EU, Regulation (EU) 2023/1113 establishes information requirements for transfers of funds and certain crypto-assets within its scope. It is binding legislation; its applicability, exceptions and detailed duties need to be assessed for the business concerned. Screening software does not itself satisfy the collection, verification or exchange requirements.
Operationally, decide what happens when required information is absent, arrives late or changes after an earlier check. Keep the information-handling outcome separate from the sanctions result. Passing a message to another provider is not evidence that its parties were screened, and screening those parties is not evidence that the required message was exchanged.
After onboarding: manage change and repeated work
Customer information, related parties and sanctions data can change. Set review and re-screening triggers that fit the relevant requirements and policy, and identify who responds when new information changes an earlier assessment. There is no universal review interval for every VASP or customer.
Checklynx customer records can support dashboard-configured ongoing monitoring. That is re-screening of customer records, not observation of on-chain transactions or behavioural crypto monitoring. The current public API does not configure or execute that monitoring.
Connect any new finding to the relevant customer or transfer review rather than overwriting an earlier result. Keep the earlier decision intelligible: what was known, what was checked and which later information prompted a new review.
Make evidence useful without rebuilding it manually
Documentation becomes expensive when analysts repeatedly copy names, search outputs and transaction references into separate notes. Agree which system retains each part of the record so the same context can support initial review, escalation and later assurance work.
For a transfer review, keep the client transfer reference, screened subjects, supplied inputs, execution time and configuration, results, case reference where applicable, reviewer rationale and authorised outcome connected. Limit access to personal and financial information and follow the firm's retention policy. The sanctions-alert investigation guide provides the detailed documentation method.
Checklynx transaction runs provide retrievable screening evidence and may link actionable results to a case. Direct AML checks do not create customer or case records, so an integration using those checks must retain its own decision record. Choose the model with that documentation responsibility in view.
Use the technical acceptance requirements for engineering tests and the sanctions software buyer guide for vendor evaluation.
Fit Checklynx into your crypto screening workflow
Checklynx supports the screening and review layer: customer and entity sanctions/PEP checks, supplied transfer parties, supported wallet-address sanctions checks, and a separate adverse-media workflow. Your team retains responsibility for the broader control design and decisions.
Bring one onboarding example and one transfer example, including the parties, identifiers, review owner and evidence you need to retain. The crypto and VASP screening solution shows where Checklynx can fit and which controls need separate systems.