AML Monitoring and Pre-Signing KYT Screening for Fintechs

TL;DR

• The Travel Rule is now live in 85 jurisdictions, and FATF’s March 2026 data shows stablecoins make up 84% of flagged transaction volume. Regulators are now focused on exactly where in your execution flow your screening runs.
• KYT tools give you a risk score on an address, but your custody layer is what decides whether a transaction executes. These two systems must be connected before signing to effectively block high-risk transfers.
• While SaaS custody requires manual integration to support pre-signing screening, self-hosted custody gives you a native cryptographic intercept point.

As of early 2026, 85 jurisdictions had enacted Travel Rule requirements (up from 65 in 2024). However, FATF data and analyses indicate that approximately 59% of these jurisdictions have yet to take meaningful enforcement action against non-compliant VASPs. 

Meanwhile, the FATF’s March 2026 Targeted Report on Stablecoins highlighted that stablecoins accounted for 84% of illicit virtual asset transaction volume in 2025.

In mature jurisdictions, simply having a KYT tool on your compliance stack is no longer enough. Regulators now audit your flow to confirm screening happens before a transaction is signed.

Why KYT Tools Alone Cannot Stop Transactions

KYT (Know Your Transaction) tools analyze blockchain data to return a risk score and its underlying context—entity labels, fund flow traces, and VASP scoring. But this output is purely advisory. Whether a transaction is blocked, approved, or escalated depends entirely on your custody platform's policy engine, meaning these two components must be wired together before execution.

Many teams set up a KYT tool, monitor the dashboard, and consider the job done. This setup provides visibility for post-transaction reporting, which satisfies some jurisdictions. However, under MiCA, MAS PSN01, or VASP frameworks in APAC, the expectation is stricter: high-risk transfers must be rejected before signing, not reviewed after settlement.

The intercept point depends on your custody architecture, not your KYT vendor.

How Custody Architecture Affects KYT Intercept

Whether you use SaaS custody or self-hosted MPC, pre-signing screening is technically possible in both. The difference is in who builds the integration layer and where control sits.

With Fireblocks, outgoing pre-signing screening is possible but you need to build it. You run their API Co-Signer on an Intel SGX-enabled server you operate, then build and host a Callback Handler that calls your KYT provider and returns Accept or Reject within 30 seconds. It works, but you are building inside Fireblocks' framework and their co-signer component sits in the middle of the flow.

With self-hosted ​Custody, the KYT check goes in as a webhook you configure before the signing request reaches the MPC nodes. You set it up in your own pipeline, on your own infrastructure, with no vendor component between your application and the signing decision.

Connecting KYT to Your MPC Signing Flow

The diagram below shows where KYT sits in a full custodial payment flow: step 4, right after the transaction indexer detects an incoming deposit and before the internal ledger is updated.

The same pattern applies to outgoing transactions. For background on how deposits enter a custodial system before this step, see How Crypto On-Ramps Work.

For outgoing transactions, here is a working address screening proxy using Fystack's DD.xyz integration:

const express = require('express');
const axios = require('axios');
require('dotenv').config();
 
const app = express();
const WEBACY_API_KEY = process.env.WEBACY_API_KEY;
 
app.use(express.json());
 
app.get('/api/address/:address', async (req, res) => {
  try {
    const { address } = req.params;
    const response = await axios.get(
      `https://api.webacy.com/addresses/${address}`,
      { headers: { 'accept': 'application/json', 'x-api-key': WEBACY_API_KEY } }
    );
    res.json(response.data);
  } catch (error) {
    res.status(500).json({ error: 'Failed to fetch address data' });
  }
});
 
app.listen(process.env.PORT || 3001);

The KYT result on its own is advisory. What decides whether a transaction proceeds, gets blocked, or gets sent for manual review is the policy engine. Fystack's programmable policy engine evaluates the KYT output against your rules before the signing step reaches the MPC nodes. A basic withdrawal policy looks like this:

{
  "version": "2024-10-24",
  "default_effect": "DENY",
  "policies": [
    {
      "name": "withdrawal-override",
      "rules": [
        {
          "id": "deny_exceed_amount",
          "effect": "DENY",
          "condition": "transaction.amount_numeric > 99.9"
        },
        {
          "id": "allow_stablecoin_transfer",
          "effect": "ALLOW",
          "condition": "transaction.asset.symbol in ['USDC', 'USDT']"
        }
      ]
    }
  ]
}

Effect precedence matters in a custody context.

By default, rule ordering determines the outcome, which means a misconfigured ALLOW rule placed before a DENY can let a transaction through. The engine's WithEffectPrecedence option removes that risk: you declare the priority hierarchy once and the engine enforces it regardless of rule order.

engine, err := policy.CompileDocument(doc,
    policy.WithEffectPrecedence(policy.EffectDeny, EffectReview, policy.EffectAllow),
)

With this configuration, a DENY always wins over a REVIEW or ALLOW.

A transaction that matches both an ALLOW rule and a DENY rule gets blocked. The signing layer only receives transactions that cleared both the KYT check and the policy evaluation.

Fystack's Risk Assessment Dashboard is built on the DD.xyz integration. It runs due diligence checks and address poisoning detection on every withdrawal address before the signing request is created.

 Top KYT Providers for Crypto Businesses

All three provide address screening via REST API, so they can sit in front of your signing step regardless of custody architecture. The decision between them comes down to the regulatory framework you operate under, your chain coverage requirements, and pricing at your transaction volume.

Build AML Screening Into Your Signing Layer

Self-hosted MPC gives you the intercept point directly. You control where in the flow the check fires, which provider it calls, and what happens when it returns a flag. Fystack's mpcium is an open-source MPC node daemon you deploy on your own infrastructure. The signing pipeline is yours to extend.

If you are mapping your KYT integration into a self-hosted custody setup, tell us where you are and our team will follow up.

Frequently Asked Questions (FAQs)