Compliance and regulatory consulting for a crypto project

Why crypto project compliance cannot be addressed with a template

Almost every project arrives with a ready-made crypto project compliance template: anti-money laundering, customer identification, procedures for responding to requests from authorities.

The problem is not that documents are missing, but that they were written to an average sample and do not describe the real operating model — where funds come from, who the counterparty is, through which services withdrawals are made.

FATF and local regulators look not at whether a policy exists, but at the verifiable link between the policy and actual transactions.

The first point of failure is unverified sources of funds. If the platform does not link an incoming transfer to a verified customer and the risk rating assigned to them, a large deposit remains unexplained, and that is exactly what will be requested.

The second is a mismatch between policy and practice: the document sets limits and manual review above a threshold, while in the system transactions pass automatically and no one records exceptions.

The third is reporting that cannot be substantiated. Customer decisions live in internal systems, tickets, and correspondence; there is no log of who approved a transaction, when, and on what grounds.

During an audit, such a report is reconstructed over weeks and still does not reconcile with the on-chain export.

The cost of error is the risk of blocked crypto operations: partner banks and payment providers restrict servicing, the settlement framework closes, and restoring it takes months and requires an already prepared evidence package.

We explain how a regulatory framework is built for a specific jurisdiction and operating model that passes an audit rather than imitates it.

Measurable effect: fewer blocks, faster approvals

A crypto project's regulatory framework is a combination of rules, screening, and logs that make it possible to reconstruct the history of every decision. A regulator's audit looks at traceability: who confirmed the source of funds, when sanctions screening was triggered.

If this is collected manually from correspondence and spreadsheets, audit readiness is measured in weeks of analyst work.

After automation, the picture changes: sanctions screening of customers runs at onboarding and on every material change to the profile, and matches are sent for review within a fixed deadline.

The share of transactions without manual intervention grows, and approval time is reduced from days to hours.

Requirements of FATF and local supervisors converge: a decision must be explainable and reproducible after the fact. Therefore, the decision log and rule versions are stored alongside the transaction — the export for an audit is generated in minutes.

Reducing the risk of license revocation is a consequence, not a slogan: violations are recorded early and closed before escalation. We take metrics from compliance processes — share of automated decisions, average review time, number of open exceptions — not from a presentation.

Crypto project compliance: support modes and their limitations

The support format depends not on the size of the project team, but on the mode in which it works with the regulator — notification or licensed.

This determines the scope of processes: in some cases it is enough to implement customer identification, sanctions screening, and transaction monitoring, while in others separate custody of customer funds, the Travel Rule, and regular reporting are added.

A one-time audit and ongoing support answer different questions: the first — “what prevents legal operation now,” the second keeps the answer current when requirements change, jurisdictions or products are added.

In practice, a combination is chosen more often: project implementation, then support with a review once per reporting cycle.

Responsibility for the decision remains with the operator. We prepare processes, internal rules, and reporting forms, but the signature and choice of interpretation are up to your compliance officer. We state this boundary before the start, not at the moment of an audit.

Stages of building a project's regulatory framework

A regulatory framework is not a folder with policies, but a set of checks built into the transaction path itself: from receipt of funds to reporting.

That is why we build it from facts, not from a template — if the rules describe a product that does not exist, the first mismatch breaks the structure. The order of work is as follows.

1. Review of current operations: which assets are accepted and withdrawn, who the counterparties are, where the project holds funds and where the user holds keys themselves, in which jurisdictions customers are located.
2. Classification of the token and operations — the regulatory mode depends on it: payment instrument, valuable asset, utility token. We mark up not the entire product, but each circulation scenario, so that rules apply precisely.
3. Fund and data flow scheme: the map “source → project account → withdrawal,” the points where the chain can break, and the places where manual confirmation is needed.
4. Setup of anti-money laundering procedures and rules: customer due diligence levels, amount thresholds, checks against sanctions lists, blocking and unfreezing procedures, decision matrix.
5. Testing on real scenarios: running transactions through the framework, measuring the share of false positives and manual reviews, adjusting thresholds — so that the flow does not stall on typical customers.
6. Preparation of reporting to the regulator: composition and frequency of reports, export formats, responsible persons, retention periods for supporting documents.
7. Handover to the team: policies in an executable form, audit logs, employee training, and the procedure for revising rules when the product changes.

Policies, regulations, and schemes we hand over to the team

We hand over not a report “for the shelf,” but a working package of documents with assigned owners and a review date — the team can then maintain control independently, without ongoing support from our side.

• Crypto policy and procedures package — customer identification procedures, checks against sanctions and risk lists, rules for receiving and sending funds, requirements for retaining evidence for each transaction.
• Role and data access rights matrix — who sees personal data, who works with transaction history, who approves exceptions; access is granted on a least-privilege basis and logged.
• Data and reporting flow scheme — from transaction receipt to report to the regulator: where data originates, where it is stored, who accesses it and when, which exports are generated automatically.
• Crypto internal transaction control procedure — control points, segregation of duties (one employee initiates, another confirms), periodic reconciliations, and the procedure for reviewing discrepancies.
• Response scenarios — a request from a bank or regulator, freezing of funds, contact from law enforcement, an incident involving key access: who makes the decision, whom they notify, and within what timeframe.
• Instructions for the compliance team — step-by-step guides for the first line: what to check at onboarding, which signs to consider suspicious, where to escalate, and when to record a refusal.
• Crypto project risk map — a list with likelihood assessment, owner, and planned measure for each item, plus a log of decisions made and exceptions.

We deliver documents in editable form with role markup, so that new employees are onboarded into the process according to instructions, not verbal agreements.

Project review: from fragmented procedures to transparent reporting

The client is a crypto service with exchange and asset custody.

Regulatory audits followed a schedule, but each turned into a scramble: accounting was kept in three systems, the origin of funds for some addresses was reconstructed manually from statements, and Chainalysis analytics were applied selectively — its findings did not reconcile with the internal register.

What it was like before the review

The share of transactions requiring manual review remained at 18% — over a hundred cases per month, each taking 20–40 minutes of analyst work.

Reporting was prepared over three weeks: exports were consolidated in spreadsheets, discrepancies were found by eye, and the decision history for each transaction was reconstructed from correspondence.

Of ten regulator requests, seven went to escalation to lawyers: there was nothing to substantiate the data source with.

What was changed and what the result was

We assembled a single transaction register with a mandatory set of fields: address, source of receipt, risk assessment, link to the primary document, decision made, and responsible person.

Review rules were formalized as a policy with thresholds — typical cases are closed automatically, and only what falls outside the framework goes to a human.

The share of disputed transactions fell from 18% to 4%, reporting preparation was reduced from three weeks to four days, and nine out of ten requests are closed within the team without escalation.

We separately recorded a policy revision log: during an audit it is visible which version of the rules a decision was made under and when it came into force.

What to do if operations were already conducted outside the regulated field?

There is no complete clean slate during a transition: the regulator looks not at the absence of a license, but at whether the picture of operations conducted outside the regulated field can be reconstructed.

The minimum starting point is a transaction register with attribution: counterparty, direction, basis, source of funds. Data collected piecemeal is reconstructed from exports and exchange histories, and disclosure is prepared based on it.

The scope of disclosure and frequency of reporting are set by the mode you are moving into. The notification regime checks activity and internal rules, while the licensed one also checks structure, sources of capital, and customer due diligence procedures.

Reporting requirements by jurisdiction differ not only in forms but also in logic: in some places periodic reports on volumes are expected, in others notifications about transactions above a threshold.

That is why the data model is built once, with attributes for jurisdiction, mode, and thresholds, and forms are assembled from it.

The practical order is as follows: inventory of past operations, assessment of discrepancies with the target regime, transfer of operations into the regulated framework without stopping the service. Describe the task — we will come back with an estimate and a plan.

Technical concerns: licenses, reporting, audits

Concerns usually arise at three points: whether working procedures need to be reworked, what to answer the bank, and when to revise policies. Below are short answers that serve as the starting point for reviewing a specific situation.

A bank request about the origin of funds has arrived — what should be prepared?

The package is assembled in advance: transaction history by address with dates and counterparties, an analytics report on address risk, customer due diligence results, and an explanation of the transaction economics.

If this is assembled manually over a week, the bottleneck is closed by a procedure and a one-click export.

How often should compliance policies be updated?

Scheduled review — once a year; unscheduled — when requirements change, a new product is launched, or a partner bank is connected. Versions are recorded with date and owner: during an audit, what matters is not the folder with the document, but the history of its changes.

Is a license required and what happens without one?

Banks refusing servicing and freezing fiat flows, regulator orders, inability to legally connect payment settlements. Technically the project continues to operate, but it stops scaling: partners require documents that do not exist.

Let's start with a review of your current transaction scheme

It is enough to send what you already have: a fund flow scheme, a list of legal entities with jurisdictions, current customer due diligence rules, and a short product description.

There is no need to prepare a document package in advance — gaps in the description itself show where the transaction framework is not covered. Next, we check the scheme point by point:

• Legal entity structure and jurisdictions: where the activity is registered, who holds the accounts, and how they are connected to each other.
• Movement of customer funds — receipt, custody, withdrawal, exchange: at which step the obligation for checks arises.
• Customer and counterparty identification: procedures, data sources, verification providers.
• Sanctions screening and transaction monitoring rules: thresholds, scenarios, reaction to a match.
• Licensing mode for the task: registration, notification, or operation within the existing perimeter.
• Reporting and data retention: what is recorded, within what timeframes, who prepares the export at the regulator's request.
• Roles and access within the team: who changes verification rules and approves exceptions.

We come back with a written document: a prioritized list of discrepancies, an estimate, and a compliance work plan by stages with the expected result at each one. This does not create obligations on your side — the review follows your scheme and remains with you.

Then we either fix the stages and join the implementation, or hand the framework over to the client's team — rules, procedures, and documentation with support during the transition period.

To discuss the compliance task concretely, show the current transaction scheme: we will come back with an estimate and a plan.