Know Your Transaction for On-Chain Transfers: Process and Sumsub API Integration

Crypto products have grown up fast. Not long ago, a team could treat compliance as something bolted onto the side of the product. That approach breaks down the moment you start moving real value on-chain.

If your platform supports stablecoin transfers, wallet withdrawals, treasury movements, merchant settlement, or cross-border payouts, transaction monitoring is no longer a background task. It becomes part of the product flow itself.

That is where Know Your Transaction, or KYT, stops being a compliance buzzword and starts becoming operationally important.

Most teams already understand KYC. You verify the customer, collect documents, run sanctions and PEP screening, and assign an initial risk profile. Useful, yes, but incomplete. Once funds start moving, identity checks alone will not tell you whether the next withdrawal is headed to a sanctioned wallet, whether a deposit came from a scam-linked address, or whether a pattern of activity looks like layering, mule behavior, or sanctions evasion.

KYT is the layer that covers that gap.

For companies building on-chain products, KYT is not just “AML for crypto.” It is the day-to-day system that ties together identity, wallet intelligence, transaction context, review workflows, and regulatory response. When that system is weak, growth creates risk faster than revenue. When it is well designed, the business can move faster without flying blind.

This article walks through how KYT works, what changes when the transfer happens on-chain, and how to build the flow with Sumsub’s API stack for transaction monitoring and Travel Rule support.

What is Know Your Transaction?

At its core, Know Your Transaction is the ongoing review of transaction activity in context. It does not assume that a clean onboarding result is enough. It looks at what actually happens after the customer starts using the product.

In practical terms, KYT asks questions like:

• who sent the funds,
• where the funds are going,
• how much is moving and how often,
• which asset, network, or payment rail is involved,
• which wallets or counterparties keep appearing,
• and whether this behavior matches what you would reasonably expect from that customer.

Traditional AML teams have done versions of this for years across cards, wires, ACH, and account-to-account payments. What changes in crypto is the operating environment. On-chain transfers move quickly, settle globally, and usually do not come with a graceful reversal path. Once the transaction is signed and confirmed, your options shrink.

That makes timing much more important. Detecting a problem after the fact still matters, but stopping a bad outbound transfer before broadcast matters more.

Why KYC on its own is not enough

KYC and KYT work together, but they answer different questions.

KYC answers: Who is this customer?

KYT answers: What is this customer doing with funds right now, and how risky is that behavior?

A customer can pass document checks, selfie verification, and sanctions screening without raising any concerns. A week later, that same customer may start sending funds to a newly sanctioned cluster, receiving transfers from a scam-linked wallet, or moving money in patterns that look nothing like the original risk profile. None of that would have been visible on day one.

That is the core difference. KYC gives you the starting profile. KYT tells you whether real activity still matches it.

The gap gets even wider in crypto, because:

• wallets can be created and discarded quickly,
• counterparties are not always known ahead of time,
• the same user may interact with hosted wallets, unhosted wallets, and smart contracts in the same journey,
• assets move around the clock and often across several chains,
• sanctions and illicit-wallet attribution change fast,
• and many suspicious patterns only become obvious when you combine identity data with on-chain behavior.

That is why mature crypto products do not treat KYC and KYT as two unrelated workstreams. They connect them. Onboarding data should strengthen transaction monitoring, and transaction outcomes should feed back into customer risk.

What a KYT process usually looks like

Strong KYT programs are built around an operating model, not a single vendor call. The tools may vary from one company to another, but the process is usually recognizable.

1. Start with the transaction scenarios that matter

Before anyone starts wiring up APIs or turning on rules, you need a map of the transactions your product actually handles.

For example:

• inbound crypto deposits,
• outbound withdrawals,
• internal wallet-to-wallet movements,
• fiat-to-crypto conversions,
• treasury rebalancing,
• merchant settlement,
• stablecoin payouts,
• and transfers that trigger Travel Rule obligations.

Those flows may look similar at a distance, but they do not carry the same risk. A consumer deposit into a custodial wallet is not the same as a high-value treasury transfer to an exchange. If both end up in the same generic review path, the team either drowns in noise or misses the alerts that matter.

2. Build a real transaction record, not just a hash

KYT works best when the monitoring layer sees more than bare blockchain data.

At a minimum, your internal model should capture:

• your own transaction ID,
• blockchain hash when available,
• timestamp,
• direction (in or out),
• amount,
• asset,
• chain or network,
• customer or applicant ID,
• sender wallet address,
• recipient wallet address,
• wallet ownership type,
• and product or use-case source.

If you can add more context, do it. IP address, device data, geolocation, expected transaction range, customer segment, historical velocity, and transfer purpose often make a noticeable difference. Without that extra signal, the system may still flag risky wallets, but it will struggle to make decisions that are useful to the business.

3. Screen wallets and counterparties at the right moment

This is the part most teams think of first: wallet screening.

You want to know whether the address or cluster is associated with sanctions, scams, mixers, terrorism financing, stolen funds, darknet activity, malware, gambling, or other high-risk exposure. Depending on the product and provider, that screening may happen:

• when a wallet is first linked,
• when a deposit address is generated,
• before a withdrawal is signed,
• after a transfer lands on-chain,
• or at several of those points.

Timing matters. For outbound transfers, pre-send screening is the control that really protects the business. For inbound transfers, post-receipt screening can still be useful, but only if you already know what to do when the result comes back high risk.

4. Turn signals into decisions

A good KYT setup does not stop at saying, “this wallet looks risky.” It translates data into action.

That usually means rules that combine wallet screening, sanctions hits, behavioral thresholds, transaction size, chain-specific risk, customer risk tier, and some notion of expected behavior.

A few simple examples:

• a first withdrawal to a new external wallet above a threshold goes to review,
• a transfer to a wallet with severe sanctions exposure is blocked,
• several small deposits followed by one larger withdrawal triggers enhanced review,
• an inbound transfer from a high-risk cluster temporarily limits account functionality,
• a large outgoing stablecoin payment requires extra counterparty data.

This is the moment where KYT becomes a control framework instead of a reporting exercise.

5. Route the outcome and document it properly

Once the transaction has been assessed, the system needs to do something clear with the result. In most products, the outcome is some mix of:

• approve automatically,
• hold for manual review,
• ask for more information,
• reject or freeze,
• escalate to compliance,
• or open a reportable case.

Teams often underestimate this part. They spend time integrating the screening engine and then improvise everything that happens after an alert. That is backwards. If nobody owns reviews, if no SLA exists, and if analysts have nowhere to record evidence and decisions, the “KYT program” turns into a pile of unresolved alerts.

6. Push the result back into customer risk

KYT is not finished when the individual transaction is marked approved or rejected.

If a customer repeatedly interacts with risky wallets, changes behavior sharply, or keeps landing in enhanced due diligence flows, that should change the customer record. Risk rating, limits, available features, and future friction should reflect what the system is learning.

Otherwise you end up with two disconnected machines: one for onboarding and one for transactions. Both keep collecting useful data, and neither actually learns from the other.

7. Make the whole process auditable

Every meaningful decision in the KYT flow should be explainable later.

That means keeping:

• the transaction payload that was assessed,
• the screening output,
• the rule or rules that matched,
• analyst notes if a review happened,
• timestamps,
• and the final decision.

At some point, a regulator, auditor, banking partner, or internal control team will ask why a transfer was approved, held, or rejected. “The vendor returned a score” is not a sufficient answer.

What makes on-chain KYT different from traditional monitoring

The basic logic is familiar across all payment rails: watch behavior, score risk, and take action. On-chain transfers make that logic harder in a few specific ways.

Wallets are identifiers, not identities

A blockchain address tells you where funds moved. It does not tell you who controls the wallet.

Sometimes you know exactly who owns it, because it belongs to your customer or your own treasury. Often you do not. In many flows, all you really have is a sending address, a receiving address, and whatever attribution your monitoring provider can infer.

That is why identity and wallet intelligence have to work together. On-chain monitoring without user context is too thin. User verification without wallet monitoring is just as incomplete.

The data is more open, and expectations are higher

In banking, a lot of transaction data lives inside the walls of participating institutions. On public blockchains, more of the trail is visible by default.

That is helpful, but it also raises the bar. If a transfer path, sanctions connection, or contract interaction is visible on-chain, regulators and counterparties will expect you to use that information responsibly.

The transaction lifecycle is different

Card payments, wires, and ACH have familiar lifecycle stages and, in many cases, at least some room to intervene before final settlement. Crypto transfers follow a different path: wallet creation, address collection, whitelisting, signing, broadcast, confirmation, and post-settlement reconciliation.

Your controls need to line up with those exact moments. If screening only happens after broadcast, you may be learning the most important fact too late.

Hosted and unhosted wallets are not the same thing

A transfer between regulated providers is not operationally identical to a transfer to a self-hosted wallet. The data you can collect, what you can verify, and what due diligence makes sense all change.

That is why wallet type should be a first-class field in the KYT model, not a note buried in a case comment.

Chains have their own quirks

Even when the asset looks the same at the product layer, the network underneath can change everything.

USDT on Ethereum, Tron, and Solana may all show up to the customer as “USDT,” but monitoring quality, transaction cost, data availability, risk patterns, and operational handling can differ a lot from one chain to another. Chain data should influence rules and routing, not sit in the payload as forgettable metadata.

A practical architecture for KYT in crypto products

At a high level, the flow is straightforward. Your backend creates or receives a transaction intent, enriches it with customer and wallet context, sends it to the monitoring layer, receives a result, and maps that result into product actions.

A simple version looks like this:

1. Your backend creates or receives a transaction intent.
2. It enriches that record with customer, wallet, chain, and device context.
3. A monitoring layer sends the normalized payload to a KYT provider.
4. Rules and blockchain screening return a decision or review status.
5. Your orchestration layer maps that outcome into product behavior.
6. Webhooks and internal events update the case, wallet status, and customer risk.

The orchestration layer in the middle is the part that saves you later.

If the UI or wallet service talks directly in vendor-specific payloads, every rule change or product expansion becomes harder than it needs to be. A thin internal transaction model gives you room to breathe. It lets you reuse logic across chains, compare or swap providers later, test rule changes before launch, and keep your internal audit trail independent of any single vendor response.

That matters even more once the business grows beyond one crypto use case.

How Sumsub fits into the picture

Many teams know Sumsub first for onboarding and identity verification, but that is only part of the story. For crypto products, the useful thing is that Sumsub can sit across several related layers: applicant data, transaction monitoring, review workflows, and Travel Rule handling.

In practice, Sumsub can help you:

• submit and monitor crypto transactions,
• link those transactions to existing applicants or create flows for non-existing applicants,
• apply rules and send outcomes into review,
• support Travel Rule data exchange,
• query existing transactions to avoid duplicates,
• and receive status updates through webhooks.

That does not remove the need for your own orchestration or policy model. It just means Sumsub can act as a solid execution layer if you send the right context and design the surrounding workflow carefully.

How to implement KYT with the Sumsub API

The easiest way to think about a Sumsub integration is this: you are not sending a transaction hash out for a yes-or-no answer. You are building a workflow.

That workflow should identify the customer or entity, normalize the transfer, submit it into KYT, react to asynchronous outcomes, and keep your internal status aligned with whatever decision comes back.

Here is a practical implementation approach.

1. Define your internal transaction schema first

Before you touch the API, decide what your own product considers a monitored transaction. Sumsub’s model should map to that schema, not replace it.

At minimum, that internal object should include:

• txnId
• txnDate
• direction
• amount
• currencyCode
• currencyType
• cryptoChain
• paymentTxnId
• applicant.externalUserId
• applicant.paymentMethod.accountId
• counterparty.paymentMethod.accountId
• wallet ownership type
• transaction purpose
• product source

Getting this right early saves a lot of pain later, especially when new chains, new workflows, or additional monitoring providers enter the picture.

2. Decide exactly when a transaction should be submitted

Outbound and inbound transfers should not follow the same logic by default.

For outbound flows, the safer pattern is usually:

• create the transfer intent,
• collect the required counterparty information,
• submit to KYT,
• wait for an acceptable decision or status,
• then proceed to signing and broadcast.

For inbound flows, the sequence is often closer to this:

• detect the deposit or transfer,
• enrich it with wallet and customer context,
• submit to KYT,
• then credit immediately, credit with restrictions, or hold it based on policy.

A lot of teams get this wrong by forcing both directions into one uniform process. Incoming and outgoing on-chain transfers do not share the same reversibility or risk profile, so the control model should not pretend they do.

3. Keep authentication on the server side

Sumsub’s REST API uses header-based authentication. Requests need:

• X-App-Token
• X-App-Access-Ts
• X-App-Access-Sig

The signature is HMAC-based and depends on the request details, so it should be generated by your backend, never by the client app. One small but important operational detail: keep your server clock synchronized. Timestamp drift is one of the easiest ways to create frustrating authentication failures.

4. Submit transactions through the right KYT path

Sumsub supports transaction submission for existing applicants and non-existing applicants. That distinction matters more than it may seem at first glance.

If the user already exists in your compliance system and has a stable external identifier, use the existing-applicant route. It keeps the relationship between onboarding data and transaction monitoring clean.

If the transfer arrives before that relationship exists, or if you are handling a Travel Rule scenario that calls for a different setup, use the non-existing-applicant flow and attach the relevant entity details there.

For on-chain use cases, the payload should usually include both identity context and transfer context. A simplified example looks like this:

{
  "txnId": "tx-out-2026-000145",
  "txnDate": "2026-03-12 14:05:31+0000",
  "applicant": {
    "externalUserId": "usr_24891",
    "type": "individual",
    "paymentMethod": {
      "type": "crypto",
      "accountId": "0x8e4d...d241"
    }
  },
  "counterparty": {
    "type": "individual",
    "paymentMethod": {
      "type": "crypto",
      "accountId": "0x9b6f...c900"
    }
  },
  "type": "travelRule",
  "info": {
    "type": "On-chain transfer",
    "direction": "out",
    "amount": 1250.00,
    "currencyCode": "USDT",
    "currencyType": "crypto",
    "paymentTxnId": "0x4d8d2f0b1b..."
  }
}

The exact list of mandatory fields should depend on the transfer type, wallet type, jurisdiction, and whether the payment falls under Travel Rule requirements. A common mistake is sending too little context and assuming the provider will somehow fill in the gaps later.

5. Separate finance and travelRule cases on purpose

One useful detail in Sumsub’s model is the ability to distinguish standard financial monitoring from Travel Rule-related processing.

That matters because the workflow is different. A regular monitored crypto transfer may only require wallet screening, rule evaluation, and a release-or-hold decision. A Travel Rule transfer may also require originator and beneficiary data, protocol-level exchange, and duplicate checks if the counterparty VASP is already present in the same ecosystem.

Do not hide that distinction in free text. Make it explicit in the payload and in your internal routing logic.

6. Use transaction queries to prevent duplicates

A useful pattern in Sumsub’s KYT stack is querying existing transactions with filters before you create or process a new record. That helps with mirrored inbound and outbound Travel Rule flows and with any case where the operations team needs to confirm that a blockchain transfer has already been registered.

In the Sumsub reference used for this implementation, transactions can be queried through:

GET /resources/kyt/txns/query/-

Supported filters include fields such as:

• data.type
• data.txnDate
• data.info.paymentTxnId
• data.info.direction
• data.info.currencyCode
• data.info.cryptoParams.cryptoChain
• data.info.amount
• data.applicant.paymentMethod.accountId
• data.counterparty.paymentMethod.accountId

That lets you check whether an inbound Travel Rule transfer with a specific blockchain hash, wallet, chain, and direction is already on record before creating another entry.

For example:

GET /resources/kyt/txns/query/-;data.type=travelRule;data.info.direction=in;data.info.paymentTxnId=0x4d8d2f0b1b...?order=-createdAt

This sounds minor until duplicate records start polluting analyst queues, distorting metrics, and muddying reporting.

7. Design for asynchronous outcomes

KYT is not really a clean request-response problem.

Even if the submission call succeeds immediately, the business-relevant status may show up later, after rules finish evaluating, screening completes, or a reviewer makes a decision. That is why webhooks and internal state handling deserve as much attention as the initial API call.

A sensible pattern looks like this:

• accept the initial acknowledgment,
• store the transaction internally in a submitted state,
• listen for webhook updates,
• map Sumsub statuses into your own internal states,
• and only unlock the next product action when policy says it is safe.

The exact webhook event set can change over time, so it is usually safer to centralize webhook parsing behind a versioned handler instead of scattering event-name assumptions across different services.

8. Build the manual review flow before you need it

If a transaction lands in onHold, everyone should already know what happens next.

At minimum, the review team should be able to see:

• the full transaction details,
• the wallet addresses involved,
• the chain and asset,
• the blockchain hash,
• the matched rules or reason for hold,
• the customer profile,
• previous transaction history,
• and a place to document the final decision.

Most KYT projects do not fail because the API is impossible to integrate. They fail because manual review was treated as somebody else’s problem until the first queue started piling up.

9. Feed KYT decisions back into product controls

Once a risk outcome comes back, the product should react in a consistent way.

That may mean:

• adding friction to future withdrawals,
• requiring step-up verification,
• freezing a linked wallet,
• lowering payout limits,
• forcing address re-verification,
• or escalating the customer into enhanced due diligence.

This is the point where transaction monitoring becomes a live control layer instead of a reporting artifact.

10. Keep wallet intelligence and Travel Rule data connected

A common trap in crypto products is splitting transaction monitoring, wallet screening, and Travel Rule handling into separate streams with separate owners and separate data models.

That fragmentation creates work for analysts and weakens decisions. If one system knows the wallet, another knows the customer, and a third knows the reporting obligation, someone ends up stitching the truth together by hand.

With Sumsub, the stronger pattern is to let applicant data, transaction data, and Travel Rule context reinforce each other. Your orchestration layer should make that connection obvious.

Common mistakes in KYT implementations

Across fintech and crypto products, the same issues show up again and again.

Treating KYT like vendor setup instead of product design

A vendor can give you screening, rules, APIs, and workflow support. It cannot define your risk appetite, release policy, customer experience, or escalation logic for you. Those are product and operating decisions.

Monitoring only after broadcast

For outbound on-chain transfers, waiting until after broadcast often means acting after the damage is already done. If you can screen before the point of no return, you should.

Sending too little context

If the provider only sees a hash, an asset, and an amount, you are asking it to make decisions with one hand tied behind its back. Better context almost always improves outcomes.

Ignoring wallet ownership

Treasury wallets, customer-owned wallets, hosted exchange wallets, and unhosted wallets should not all flow through the exact same logic.

Underestimating operations

A review queue without ownership is not a control. It is just a backlog with compliance consequences.

Never tuning thresholds

Rules that are never revisited do not stay effective. Over time, false positives quietly tax the business while false negatives quietly increase exposure. Often both problems show up together.

Final takeaway

Know Your Transaction is not optional anymore for teams building serious crypto or stablecoin products. The more your business depends on fast on-chain value transfer, the more you need monitoring that works before, during, and after the transaction lifecycle.

The most important shift is to stop thinking about KYT as a single screening step. It is a cross-functional capability that connects KYC, wallet intelligence, review operations, rules, and product controls.

Sumsub can play a strong role in that architecture because it brings together transaction monitoring, applicant context, review workflows, and Travel Rule support in one operating model. But the result still depends on your choices: what data you send, when you screen, how you handle holds, and whether transaction outcomes actually change customer risk and product behavior.