Crypto Transaction Monitoring: Integration Architecture Guide
Crypto transaction monitoring for EU CASPs covering KYT versus KYC, webhook and polling integration patterns, reorg-safe verdict caching, whale-wallet pagination limits, account abstraction edge cases and the EU regulatory requirements that make it mandatory.
15 min read
60 views
Key takeaways: crypto transaction monitoring integration 5
The architecture decisions that matter most when integrating KYT screening into an EU CASP's deposit and withdrawal flow, from check orchestration through reorg-safe caching to what EU regulation actually mandates.
- Async check orchestrator is the default pattern A pending-state response backed by a background worker mirrors vendor ~2-minute pending/poll cycles and avoids colliding with a standard 29-second gateway timeout.
- Webhook and polling are complementary, not a choice Webhook is the fast path for continuous monitoring, polling/reconciliation is the safety net and a feed-change rescreening scheduler catches passive sanctions-list updates that produce no on-chain event.
- Cache verdicts by chain state, not just address Key the cache on tag snapshot, block height and finality, scoring-methodology version and price-data version, and score only against final blocks so a reorg cannot leave a stale verdict standing.
- Whale wallets and smart-contract wallets need dedicated handling A query governor with a hard page or compute-unit cap keeps whale-wallet pagination from running to tens of minutes, and classifying an address as a contract or an EOA before scoring keeps account-abstraction wallets from silently escaping deposit-clustering heuristics.
- EU regulation makes KYT mandatory and evidentiary EBA GL 21.11/21.13, the AMLR and the Travel Rule without a minimum threshold under MiCA make transaction monitoring mandatory for every EU CASP, and AMLR Article 77 requires unredacted, admissible records retained five years, extendable another five.
Every EU crypto business that touches customer transfers is expected to run crypto transaction monitoring: some form of on-chain screening on every transfer it processes. Most of what gets published about it reads like vendor marketing, not the integrator-side engineering guide a backend team needs: where screening sits in a deposit or withdrawal flow, poll or webhook, how a verdict cache survives a reorg, what breaks once a counterparty wallet is a smart contract. This guide covers that ground, built on architecture work from a production CASP integration we delivered as part of our Web3 FinTech development practice, plus the EU rules, AMLR, TFR, the EBA guidelines and MiCA, that define what "monitoring" has to mean.
In short: crypto transaction monitoring is an engineering problem vendor documentation under-specifies, not just a compliance checkbox. A workable default is async screening: a check orchestrator returning a pending state immediately, webhook delivery backed by polling reconciliation and verdicts cached against a chain-state snapshot rather than an address alone, so a reorg cannot leave a stale verdict standing. Screening quality itself, how reliably any engine catches illicit activity, is genuinely hard to measure and this guide does not claim otherwise. KYT complements KYC, it does not replace it.
What crypto transaction monitoring does and how it differs from KYC
Know-your-transaction (KYT) screening evaluates a blockchain address or transfer against risk data, sanctions lists, stolen-fund tags, mixer and darknet labels and exchange labels, and returns a verdict. On-chain screening is close to exact-match string or hash matching against blacklists: an address either carries a flag or it does not. Person screening for KYC, sanctions and PEP matching, is probabilistic fuzzy matching across name transliteration and aliasing, which is why it needs a human review queue for ambiguous scores. One open-source identity-matching option, yente, still routes gray-zone scores, roughly 0.5 to 0.7, to mandatory human review.
The two checks also run on different cadences and keys. KYC runs at onboarding and re-screens on sanctions-list updates, keyed on identity attributes. KYT evaluates one specific transfer's direction, asset, amount and timestamp in near real time, keyed on the transaction itself. An address-level aggregate check rolling up a wallet's whole history is a weaker, related capability: it dilutes a recent illicit transfer inside older clean activity, not a substitute for transfer-level monitoring.
| Dimension | KYT (transaction monitoring) | KYC (identity and person screening) |
|---|---|---|
| What it checks | An address or transfer against on-chain risk data and tags | A person's identity against sanctions, PEP and watch lists |
| Matching model | Deterministic, exact string or hash match | Probabilistic, fuzzy name matching with a human review queue |
| Cadence | Continuous, per transaction or transfer | Onboarding-time, plus rescreening on list updates |
| Key | Address, transfer, block height and finality | Customer identity attributes: name, date of birth, residence |
| Regulatory anchor | EBA GL 21.11 and 21.13 transaction monitoring, AMLR Article 40 | AMLR customer due diligence and PEP rules (Articles 20, 42-46), standard KYC onboarding |
The two are complementary pillars of the same AML program, not substitutes for one another. MiCA and the AMLR treat them as separate mandatory controls. If identity-side onboarding and the Travel Rule are the piece you are scoping, our guide to MiCA KYC requirements covers that half in more depth.
Where screening sits in a CASP architecture
Screening rarely fits cleanly into a synchronous request. A withdrawal endpoint that runs address screening, price lookups and enrichment inline, then returns a result in one HTTP request, collides with real blockchain-data latency. Standard cloud API gateways, AWS is the commonly cited example, enforce a hard execution ceiling around 29 seconds, and a chain of external screening calls comfortably exceeds that on anything but a trivial check.
The response is a dedicated async component, a check orchestrator: an endpoint that returns an immediate pending state and hands the work to a background worker that polls or listens for completion, mirroring the pending-and-poll cycle one incumbent KYT vendor documents, with average check duration around two minutes. The caller then either polls a status endpoint or receives a webhook when the verdict is ready.
How strict the response has to be is a policy decision, not a fixed rule. A withdrawal that clears screening synchronously before funds leave, versus a deposit credited immediately but flagged asynchronously with a later hold on high risk, are different risk postures: the first protects the CASP more at the cost of felt latency, the second protects customer experience but leaves a window where funds move before the verdict lands. Many integrations start from block-on-withdrawal, flag-on-deposit, then tighten for higher-risk assets.
A verdict is only useful once something acts on it. That means a hold-and-release state machine on withdrawals that a flagged transfer enters and a clean one skips; an escalation path that routes a flag to the compliance team and, where warranted, into a suspicious-transaction report; and a customer-facing freeze flow that holds funds without disclosing why, since telling a flagged customer they are under investigation is a tipping-off risk in its own right. Wiring the check orchestrator to a verdict with nowhere to go is a common integration gap: the screening call succeeds and nothing downstream changes behavior.
Webhooks vs polling: the failure modes
Two models cover most of the KYT vendor surface: polling a status endpoint for one-off checks, and subscribing to a webhook for ongoing monitoring. Polling is straightforward: submit the address, receive a truncated pending object, then poll a recheck endpoint until it resolves. The failure modes are rate limits and orphaned polls: one vendor's documented ceiling of 5 requests per second returns HTTP 429 on excess, so a poller needs backoff, and an unresolved check needs a timeout and a dead-letter path.
Webhooks solve continuous monitoring more naturally: a subscribe endpoint registers an address with a configurable alert threshold, one vendor's documented example uses 60 percent, and a receiver gets a signed payload (HMAC-SHA256) when activity crosses it. A custom-stack equivalent on a provider's free-tier address-activity webhooks (five webhooks, 100,000 addresses, roughly 40 compute units per event) is not a drop-in replacement, since an activity webhook only fires on on-chain activity: an address newly added to a sanctions list produces no event and gets silently missed. A feed-change rescreening scheduler, re-checking monitored addresses against updated list data on a timer, is a required companion.
| Dimension | Webhook (subscribe and push) | Polling (pull) |
|---|---|---|
| Delivery trigger | On-chain activity crossing a configured threshold | Client-initiated status check |
| What it misses | Passive list updates with no on-chain event, needs a rescreening scheduler | Nothing structurally, but wastes calls while a check is pending |
| Ordering and dedup | Not guaranteed, reorgs and backfills can redeliver or reorder | Naturally sequential per poll |
| Failure signal | Signed payload (HMAC-SHA256), verify before trusting | HTTP 429 on rate-limit excess, needs backoff |
| Reconciliation cost | Needs a periodic pull-based backfill as a safety net | Self-reconciling by design, but an unbounded poll leaks resources |
In practice the two are complementary, not a choice. A resilient integration treats the webhook as the fast path and polling, or a periodic reconciliation pass, as the safety net catching a dropped delivery, a reorg-invalidated notification or the list-update gap above. On the data-provider side, a tripped rate limit needs a circuit breaker that fails over to a reserve provider rather than blind-retrying a stalling endpoint, since fail-closed on legitimate customers is a self-inflicted availability problem, not a compliance one. The signature-verification discipline protecting a webhook receiver deserves the same cybersecurity services review as the rest of the integration.
Before go-live, exercise the integration against whatever sandbox mode and known-tagged test addresses the vendor offers rather than trusting production traffic to surface the edge cases. Verify webhook signature validation independently, including how the receiver behaves on a malformed or replayed payload, and rehearse an alert-replay or backfill run so a dropped-delivery recovery is a tested path rather than a first-incident improvisation.
Reorg-safe verdict caching
A screening verdict is not a fact about an address in isolation, it is a fact about an address as of a specific, provisional blockchain state. Caching it as if permanent is a defect in its own right: a verdict computed against a block that later reorganizes can go stale without the cache signaling that it happened.
The fix is to key the cache on more than the address: a snapshot of the tags in effect at check time, the block height and finality state, the scoring-methodology version and the price-data version. The policy that follows is finality-only scoring, a verdict against a non-final block is not trusted or cached until that block is final, so the snapshot stays reproducible for an audit later.
Finality is not uniform across chains, which is why it has to live in the cache key rather than be assumed. An EVM layer-2 network, Base is a concrete example, has a softer finality and reorg model than layer-1 Ethereum. What no source behind this guide supplies, deliberately, is a single universal confirmation-depth number that applies across chains: it is a policy decision your team makes per chain, not a value to copy from a blog post. A properly-keyed result cache also pays for itself economically, reported to cut external data-provider costs by roughly 30 to 60 percent, and caching daily fiat prices removes currency conversion from the real-time path.
Pagination pinning and whale wallets
Fetching a wallet's transaction history through a vendor API almost always means paginating, a first request returns a page and a cursor for the next one. Walking that cursor against a live, still-growing chain produces a specific bug class, pagination snapshot-consistency: new blocks arriving mid-fetch can make later pages return duplicate or missing records. The fix is a block-anchoring policy, pinning every paginated fetch to a fixed toBlock height rather than the chain's moving tip.
Per-page latency on a live, high-activity address ran close to two seconds per page in the testing behind this guide (2.17 seconds then 1.98 seconds, against a well-known high-volume exchange hot wallet used purely as a latency benchmark, not a screening verdict). That speed sounds fast until multiplied by page count: a wallet with roughly a million transfers across roughly a thousand pages needs tens of minutes to fetch in full, contradicting any "seconds"-level promise and colliding with the gateway timeout above. The mitigation is a query governor, a hard page or compute-unit cap for whale-looking wallets, returning an explicit insufficient_history state instead of hanging. An ordinary check runs roughly 500 compute units, under half a cent; a heavy exchange-wallet check scales toward roughly five cents purely from pagination volume, and we break down the full cost side, vendor pricing against a custom stack, in the crypto AML screening cost guide.
Multi-hop tracing, following counterparties several hops out live, has its own cost explosion: a breadth-first RPC walk at a branching factor of 10 costs roughly 26,640 compute units for a three-hop check, and at a branching factor of 100, common at exchange routers or dusting fan-out, roughly 2.42 million. The answer is a pre-indexed offline graph built as infrastructure, not recomputed live inside a request. Two related bug classes belong in the same risk register: dusting, sending sanctioned dust to trigger a false positive, and spoofed token logs, a fake contract mimicking decimals closely enough to need an authenticity check first.
Account abstraction breaks the heuristics
A meaningful share of exchange-deposit detection relies on a heuristic that predates account abstraction: deposit-address-reuse clustering, flagging an externally-owned account (EOA) as a likely exchange deposit address when it forwards close to its entire balance, documented thresholds are roughly 0.01 ETH and around 3,200 blocks, to a single destination shortly after receiving it. It is useful and narrow: measured coverage against active EOAs sits around 10.6 percent, and ERC-4337 smart-contract wallets do not follow the pattern at all, since account abstraction routes outgoing transfers through custom logic or a bundler rather than a single EOA-to-EOA sweep. The heuristic does not fail loudly, it just silently stops attributing outgoing activity to anything.
The practical response is classifying an address as a contract or an EOA before scoring it, not after. Decentralized-exchange contracts and liquidity pools break a naive in-and-out linkage the same way, since a DEX aggregator fans a single transfer out to many recipients in a pattern that looks like layering if every address is assumed to behave like a plain wallet. Contract-routed deposit schemes deserve an honest not-covered label, the same as mixer chains, multi-hop layering and cross-chain bridges, rather than folding into a single "screening" claim.
Every worked example above assumes an EVM-style account model. A UTXO chain such as Bitcoin has no EOAs, contracts or ERC-4337 wallets to classify, its clustering relies on co-spend and change-address inference instead of deposit-reuse heuristics and its finality is a probabilistic function of confirmation depth rather than a single finalized-block boundary. A CASP with Bitcoin or another UTXO chain in scope has to re-derive its clustering, finality and caching policies for that chain rather than porting the EVM defaults above.
What EU regulation actually requires
EBA guidelines: risk factors and transaction monitoring
For an EU CASP, transaction monitoring is a named, mandatory control, not an optional add-on to sanctions screening. The EBA's Risk Factors Guidelines (EBA/GL/2024/01) require "transaction monitoring tools and advanced analytics tools" (GL 21.11), run on a risk-sensitive basis to "trace the history of transactions and identify potential links with criminal activities" (21.13). That same guideline names indirect darknet exposure as a risk factor (21.5(b)(xiii)), a requirement that is hard to satisfy with one-hop-only screening; verification must rest on more than one independent source (21.12(a)) and a CASP cannot rely on a single ledger for record-keeping (21.16).
The Travel Rule and self-hosted wallet checks
The Travel Rule guidelines (EBA/GL/2024/11, effective 30 December 2024) are just as explicit: CASPs "should rely on... blockchain analytics, third-party data providers" (paragraph 77). Self-hosted wallets and mixers are named risk factors (paragraph 47); a transfer's basis must be documented (paragraph 64); acceptable self-hosted-address verification includes a Satoshi-test or message signing (paragraph 83); whitelisting is separately governed (paragraph 86). A further guideline (EBA/GL/2024/15, effective 30 December 2025) requires reliable EU sanctions screening with regular testing, keeping adverse-media screening optional.
AMLR, MiCA, DORA and GDPR: the surrounding obligations
The AML Regulation (2024/1624) sets the evidentiary bar: records must be admissible, unredacted and retained five years, extendable another five (Article 77). A CASP must demonstrate to supervisors, at all times, that controls are adequate (Article 20); self-hosted-address interactions require enhanced monitoring (Article 40); the expanded PEP definition (Article 2(34)) makes PEP-status determination mandatory at due diligence, with the PEP obligations themselves set out in Articles 42 to 46. The Transfer of Funds Regulation adds a threshold: above EUR 1,000, a CASP must assess whether a self-hosted address is owned or controlled by its client (Articles 14(5), 16(2)). MiCA sets the base obligation of robust internal controls against money-laundering risk, authorization revocable if inadequate; MiCA and the Transfer of Funds Regulation together apply the Travel Rule without a minimum threshold, so KYT ends up mandatory for every EU CASP.
Two adjacent frameworks matter for the vendor relationship. DORA governs the contract: minimum terms on data location, SLAs, cooperation and termination (Article 30(2)), plus audit and access rights and an exit strategy once the CASP classifies the vendor's function as critical or important (Article 30(3)). A critical-provider designation is a separate ESA decision (Article 31), and the contract needs due diligence before signing (Article 28(4)) alongside the register of information (Article 28(3)). GDPR, via the EDPB's 2025 blockchain guidance, treats a crypto address as personal data once linkable to a person; a tag such as "sanctions" is criminal-offense data where legitimate interest alone is insufficient, and a vendor score a CASP relies on heavily can count as an automated decision under Article 22, so human review is close to a legal expectation and a DPIA is described as mandatory.
Integration decision guide
None of the above resolves into one universal architecture. The following is a set of defaults to reason from, not a specification to copy without adjustment.
| Situation | Default pattern | Note |
|---|---|---|
| Launch-stage CASP on one or two EVM chains, moderate volume | Async check orchestrator, pending-state response backed by polling | Mirrors the roughly two-minute vendor pending cycle rather than fighting the gateway timeout |
| Ongoing address monitoring rather than one-off checks | Activity webhook plus a scheduled feed-change rescreening job | A webhook alone misses passive sanctions-list updates with no on-chain event |
| Large exchange-style wallets or router addresses in the traffic mix | Query governor with a hard page or CU cap and an explicit insufficient_history state | Full-history pagination on a whale wallet runs to tens of minutes, not seconds |
| Smart-contract and account-abstraction wallets present | Contract-vs-EOA classification before scoring, not after | Deposit-clustering heuristics silently miss ERC-4337 sweeps |
| Regulated EU CASP under AMLR, TFR and MiCA | Finality-gated verdict caching plus an evidentiary, source-traceable logging layer | AMLR Article 77 requires unredacted, admissible records retained 5 plus 5 years |
Every row above assumes the same two things: real screening is asynchronous underneath even when it looks synchronous to the caller, and resilience comes from treating webhook and polling as complementary, not from picking one.
How Pharos Production builds crypto compliance integrations
The patterns above draw on architecture and integration work from a production CASP build we delivered, evaluating and prototyping a replacement path for an incumbent crypto-AML screening vendor across check orchestration, webhook and polling integration, reorg-safe verdict caching and the EU regulatory mapping above, without publishing comparative detection-quality numbers or a false-positive or false-negative rate for any approach, since no published rate exists for the approaches described and that measurement is the part that remains unsolved. What we can help with is the engineering, the check orchestrator, webhook and polling layers, the cache-key and finality logic and the evidentiary logging your compliance team will need, as part of a custom software development engagement scoped to your CASP's chain mix, volume and risk profile.
Sources: architecture and integration findings from a production EU CASP build we delivered, cross-checked against public EBA Guidelines (GL 21 Risk Factors, GL Travel Rule, GL sanctions screening), the AML Regulation (2024/1624), the Transfer of Funds Regulation (2023/1113), MiCA, DORA and EDPB blockchain guidance. No detection-quality benchmark figures or false-positive or false-negative rates are published here; that measurement is not solved industry-wide and none exists for the approaches described.
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 5
No matches
Try a different keyword, change the topic or clear filters
-
Crypto transaction monitoring, also called KYT (know-your-transaction) screening, checks a blockchain address or transfer against risk signals such as sanctions lists, stolen-fund tags, mixer and darknet labels and exchange labels, then returns a pass or flag verdict. The matching itself is close to an exact string or hash lookup against blacklists, which sets it apart from identity-side KYC's probabilistic fuzzy matching.
Under the EBA guidelines an EU CASP treats it as a mandatory control, not an optional compliance checkbox, and it sits alongside KYC rather than standing in for it.
-
Yes. MiCA and the AMLR list them as two separate mandatory controls inside the same AML program, and neither one covers the other's gap.
KYC checks who a customer is, at onboarding and again whenever a sanctions list updates, using fuzzy name matching keyed on identity attributes. KYT checks what a specific transfer looks like, its direction, asset, amount and timestamp, in near real time using deterministic matching keyed on the transaction itself. An EU CASP has to run both.
-
Both, and treating it as an either-or choice is where integrations get into trouble. A webhook subscription is the fast path for ongoing monitoring, firing on new on-chain activity, while polling or a periodic reconciliation pass acts as the backstop for what a webhook alone misses: a dropped delivery, a notification invalidated by a reorg or an address added to a sanctions list with no on-chain event to trigger anything.
That last gap is why a scheduled rescreening job against the latest list data belongs next to the webhook, not as an afterthought.
-
A verdict only holds as of the blockchain state it was computed against, and that state is provisional until a block finalizes, so a cache that treats the verdict as permanent is broken by design. The fix is keying the cache entry on more than just the address: the tag snapshot at check time, the block height and finality state and the versions of the scoring methodology and the price data behind it.
Pair that with finality-only scoring, holding off on trusting or caching a verdict until its block is final, and a reorg cannot leave a stale result standing. Because finality behaves differently chain to chain, an EVM layer-2 such as Base settles less firmly than layer-1 Ethereum, so that policy has to be decided per chain instead of assumed.
-
Yes. The EBA's Risk Factors Guidelines (GL 21.11 and 21.13) require transaction monitoring tools run on a risk-sensitive basis, and MiCA together with the Transfer of Funds Regulation apply the Travel Rule without a minimum threshold, which makes KYT mandatory for every CASP in the EU.
The AML Regulation adds the evidentiary bar: records must be admissible, unredacted and retained five years, extendable another five, and a CASP must be able to demonstrate the adequacy of its controls to supervisors at all times.
I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.
My focus is on complex products where mistakes are costly:
- Web3 and blockchain platforms
- FinTech and regulated products
- High-load startup systems
- MVP → scale transitions
We don’t do body-shopping.
We don’t sell generic outsourcing.Instead, we help founders:
- build the right team structure from day one
- keep technical ownership and transparency
- scale delivery without losing control
- avoid vendor lock-in and hidden risks
Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.
