A crypto compliance software rollout runs five phases: assessment, proof of concept, integration, go-live, and continuous monitoring. Skip any one and screening ends up disconnected from deposits and withdrawals, or alerts ship without an owner after launch. Buying a license is the easy part. The work is wiring screening into the deposit and withdrawal flow, configuring alerts, assigning owners, testing the workflow, and tuning it after launch. This guide organizes the rollout into five phases, from assessment and proof of concept to integration, go-live, and continuous monitoring. For the broader workflow, see Phalcon Compliance. This page is part of the AML Compliance Hub.
Why Deployment Planning Matters
A tool deployed in a hurry produces three failures at once. The first is a coverage gap. A screening engine that is licensed but not wired into the deposit and withdrawal flow checks nothing until a human queries it by hand. Funds move faster than a manual query. The second is alert noise. Default risk thresholds shipped by the vendor are calibrated for a generic population, not for a specific exchange's traffic. They either flood the team with false positives or sit silent on real risk. The third is team confusion. When routing, ownership, and escalation are not defined before go-live, every alert becomes an ad hoc decision. Ad hoc decisions do not survive an examiner's review.
FinCEN requires money services businesses, including crypto exchanges, to maintain an AML program (31 CFR 1022.210) and to report suspicious transactions (31 CFR 1022.320). In practice that combination is what makes continuous transaction monitoring necessary. A tool that is licensed but not deployed into a sustained monitoring workflow leaves a gap between the regulatory duty to monitor and the control that actually runs. Examiners read that gap as a program deficiency, not as a deployment preference.
The buyer side of the problem reinforces the same point. No combination of off-the-shelf third-party tools fits an exchange's use case until those tools actually get access to internal systems, so integration, not feature count, is the underrated battle. A deployment plan is how a compliance lead turns a feature list into a working control. It is the artifact an examiner asks for when the program is reviewed.
Five-Phase Deployment Framework
A crypto compliance software deployment timeline and rollout plan runs in five phases: assessment and selection, proof-of-concept trial, system integration, go-live and rule tuning, and continuous monitoring with periodic review. Each phase has a distinct goal, a distinct owner, and a distinct exit criterion. The timeline ranges below are deployment-planning estimates, not vendor SLAs, and they compress or stretch with team size, infrastructure maturity, and the regulatory deadline driving the rollout.
| Phase | Goal | Estimated timeline | Exit criterion |
|---|---|---|---|
| 1. Assessment and selection | Match requirements to a shortlisted tool | 1 to 2 weeks | Requirements signed off, vendor selected |
| 2. Proof-of-concept trial | Validate coverage on real addresses | 1 to 2 weeks | POC report accepted |
| 3. System integration | Wire the tool into deposit and withdrawal flow | 2 to 4 weeks | API live in production path |
| 4. Go-live and rule tuning | Cut over and calibrate thresholds | 1 to 2 weeks | Alert volume within target band |
| 5. Continuous monitoring and review | Sustain coverage and re-tune | Ongoing | Quarterly review cadence set |
Phase one is requirements and selection. The compliance lead locks the use cases the tool must cover, the data sources it must read, the jurisdictions it must serve, and the plan tier the budget supports. The output is a requirements document and a vendor decision, not a feature comparison. Phase two is a proof of concept on the team's own addresses, not on a vendor demo set. The goal is to see whether the tool's risk engine covers the asset and counterparty types the exchange actually sees. The output is a POC report that either clears the tool for integration or sends the team back to phase one.
Phase three is the integration build. The tool's screening API is wired into the deposit and withdrawal flow. Alert routing is configured into a real queue, and thresholds are defined as code rather than as policy. Phase four is cutover and tuning. The tool runs in production, and the team watches alert volume and precision against an agreed target band. Thresholds move until the band holds. Phase five is the sustained cadence. The monitoring layer runs continuously, thresholds get a scheduled review, and the program is re-tuned as the threat landscape and the exchange's own traffic shift.
Fastest Path: Evaluate to API to Monitor
Phalcon Compliance supports a staged rollout. Teams can start with manual address and transaction checks, add API screening to production flows, and then enable Monitor for continuous risk updates after launch.
A deployment does not have to wait for a signed contract to produce value. Phalcon Compliance lets a compliance team run address and transaction screening interactively through the platform interface, starting on the Free tier. The tool is usable from day zero, before any contract or integration work begins. That collapses the assessment phase. A compliance officer can validate coverage on real addresses during selection rather than after procurement. The POC report in phase two is then built on real tool output rather than on a vendor slide.
The second step is API integration. API access is available only on the Scale tier, starting at $699 per month, and on the Enterprise tier; the Free, Screening Packages, and Essential tiers do not include API access. A deployment that embeds screening into the deposit and withdrawal flow has to reach the Scale tier first, and confirming that before phase three avoids building code against a tier the team cannot use. The integration build follows the same three-mode API shape, real-time, batch, and Monitor. That shape is documented in the KYT API integration blueprint for crypto exchanges, so phase three reuses that endpoint, rate-limit, and quota plan instead of designing a new one. The plan structure runs on five tiers with Pay-As-You-Go credit starting at $95, followed by Essential, Scale, and Enterprise, plus a 20 percent referral reward on qualifying spend. A team can begin on Pay-As-You-Go credit for the assessment phase and step up to Scale when the integration build starts. Screenings drawn from those tiers consume in a fixed order, Subscription quota first, then Top-up Screenings, then Referral Rewards, then Screening Packages, so the budget owner can predict which balance depletes first across the rollout.
The third step is continuous monitoring. Monitor runs on a dynamic schedule and re-analyzes already-screened addresses when their risk changes, and it does not consume the Screening quota. That matters for deployment economics. A team that goes live on the real-time gate does not have to choose between leaving already-screened addresses unwatched and burning the per-check budget on re-screening. The Monitor layer sustains coverage of the historical book while the real-time API handles new traffic. Together, the two layers turn a screening capability into a sustained monitoring program. Behind both layers, the Phalcon Compliance Risk Engine covers 17 categories of Risk Indicators and labels more than 600 million addresses, which is the coverage surface the deployment is wiring into the flow. That coverage includes sanctioned addresses keyed to the OFAC sanctions list and compliance guidance. A deployment that wires in the Risk Engine wires in the sanctioned-address baseline an examiner expects screened on every deposit and withdrawal.
Resource and Timeline Estimation
The timeline a team should plan against is not the sum of the phase ranges. It is that sum plus a buffer for the two dependencies that slip most often. The first dependency is plan gating. If the integration phase assumes API access but the team has not yet reached the Scale tier, the build waits on procurement. Confirming the tier before phase three starts is the single most important scheduling decision in the project. The second dependency is alert routing. If the webhook, ticket queue, and on-call rotation are not defined before go-live, phase four produces alert noise with no path to action. Tuning cannot start until routing is built.
A realistic full rollout for a mid-size exchange, with the compliance lead, one integration engineer, and the plan tier already confirmed, lands in the six to ten week range end to end. Phase one and two together take two to four weeks when the interactive screening path runs the proof of concept during selection. Phase three takes two to four weeks, depending on the deposit and withdrawal flow's existing shape and on whether webhook and case management are already in place. Phase four takes one to two weeks of live tuning. Phase five is ongoing and has no end date.
The risk factors that stretch the timeline are predictable. A team that defers plan-gating confirmation to the integration phase adds a procurement wait. A team that skips the POC and finds a coverage gap during go-live returns to phase one. A team that skips alert routing before cutover spends phase four building plumbing instead of tuning thresholds. None of these are tool problems. They are deployment-planning problems, and the five-phase framework surfaces them before they cost weeks.
Plan a Phalcon Compliance Deployment
A crypto compliance software deployment is finished when five things are true at once. The tool is selected against a real requirements document. The proof of concept has validated coverage on the team's own addresses. The API is wired into the deposit and withdrawal flow on the Scale tier or above. Alert routing is built, thresholds are tuned to a target band, and Monitor sustains coverage on the historical book. Plan a Phalcon Compliance deployment to start from interactive screening, step up to Scale when the integration build begins, and use Monitor to sustain coverage after go-live.