[{"data":1,"prerenderedAt":803},["ShallowReactive",2],{"content-\u002Fresources\u002Fmore\u002Freduce-false-positives-transaction-monitoring":3,"resources-category-reduce-false-positives-transaction-monitoring":691},{"id":4,"title":5,"authors":6,"body":7,"categories":6,"category":634,"categoryType":6,"compare":6,"contributors":6,"date":635,"description":636,"extension":637,"faq":638,"howto":657,"isBlog":681,"isChangelog":681,"meta":682,"navigation":684,"path":685,"pillar":681,"products":6,"rawbody":686,"role":6,"seo":687,"seoTitle":688,"stem":689,"thumbnail":6,"updated":635,"__hash__":690},"content\u002Fresources\u002Fmore\u002Freduce-false-positives-transaction-monitoring.md","How to reduce false positives in transaction monitoring without missing real risk",null,{"type":8,"value":9,"toc":619},"minimark",[10,14,23,29,48,53,56,123,126,130,133,143,158,167,170,174,177,222,229,233,236,361,368,372,375,378,384,390,396,399,403,406,409,441,444,448,451,454,465,468,487,494,498,501,539,546,550,558,565,569,572,576,613],[11,12,13],"p",{},"To reduce false positives in AML transaction monitoring, segment customers by risk and behavior, set thresholds from your own data, add secondary identifiers to screening matches, deduplicate alerts, and rank them by risk score. Then prove nothing real was lost with below-the-line testing, and document every change. Fewer alerts is the result, not the goal.",[11,15,16,17,22],{},"This article is general information, not legal advice. It assumes a monitoring program already exists; if you are still mapping the parts, start with ",[18,19,21],"a",{"href":20},"\u002Fresources\u002Fmore\u002Fwhat-is-automated-risk-monitoring-fintech","what automated risk monitoring is",".",[11,24,25],{},[26,27,28],"strong",{},"Key takeaways",[30,31,32,36,39,42,45],"ul",{},[33,34,35],"li",{},"A false positive is an alert that review closes as not suspicious. Most programs produce far more of these than real cases.",[33,37,38],{},"High alert volume is a control weakness, not a safety margin. Real cases wait in the same queue as the noise.",[33,40,41],{},"Tune with data, per customer segment, and test below the line before and after every change.",[33,43,44],{},"Automation can close narrow, explainable patterns. Possible true matches and SAR decisions stay with people.",[33,46,47],{},"Keep the rationale, the test results, and the approver for every change. That record is what an examiner reads.",[49,50,52],"h2",{"id":51},"what-counts-as-a-false-positive-in-risk-monitoring","What counts as a false positive in risk monitoring?",[11,54,55],{},"A false positive is an alert that a reviewer closes because the activity turned out to be normal. A true positive is an alert that review confirms as suspicious or as a real sanctions match.",[57,58,59,75],"table",{},[60,61,62],"thead",{},[63,64,65,69,72],"tr",{},[66,67,68],"th",{},"Term",[66,70,71],{},"Definition",[66,73,74],{},"What it tells you",[76,77,78,90,101,112],"tbody",{},[63,79,80,84,87],{},[81,82,83],"td",{},"False positive",[81,85,86],{},"An alert closed after review as not suspicious",[81,88,89],{},"How much analyst time goes to noise",[63,91,92,95,98],{},[81,93,94],{},"True positive",[81,96,97],{},"An alert confirmed as suspicious activity or a real list match",[81,99,100],{},"Whether the rule catches what it was built for",[63,102,103,106,109],{},[81,104,105],{},"Alert-to-case rate",[81,107,108],{},"Share of alerts escalated into a full investigation case",[81,110,111],{},"How often an alert needs more than a first look",[63,113,114,117,120],{},[81,115,116],{},"SAR conversion rate",[81,118,119],{},"Share of alerts, or of cases, that end in a suspicious activity report (SAR)",[81,121,122],{},"How much monitoring output is useful to law enforcement",[11,124,125],{},"Measure each one per rule and per segment. A program-wide rate hides the two rules that make most of the noise.",[49,127,129],{"id":128},"why-is-high-alert-volume-a-control-weakness","Why is high alert volume a control weakness?",[11,131,132],{},"High alert volume is a weakness because analysts can't give every alert real attention, so real cases get the same rushed review as the noise. It also signals that the rules don't fit the business, which is what regulators look for first.",[11,134,135,136,142],{},"The UK Financial Conduct Authority (FCA) says this directly in its ",[18,137,141],{"href":138,"rel":139},"https:\u002F\u002Fhandbook.fca.org.uk\u002Fhandbook\u002FFCG\u002F3\u002F2.html",[140],"nofollow","Financial Crime Guide",". Section FCG 3.2.5A lists, as poor practice, a weak control framework around automated monitoring, threshold-based rules used where they don't suit the activity, and poorly calibrated rule systems where the firm struggles to explain why a particular rule exists. Good practice in the same section includes a holistic view of customer behavior and monitoring at several levels of aggregation.",[11,144,145,146,151,152,157],{},"The Wolfsberg Group, an association of global banks that publishes financial crime standards, made the same point from the reporting side. Its ",[18,147,150],{"href":148,"rel":149},"https:\u002F\u002Fwolfsberg-group.org\u002Fresources\u002F168",[140],"2024 Statement on Effective Monitoring for Suspicious Activity"," argues that the growing volume of SARs isn't producing a proportionate gain in effective outcomes, and pushes programs toward outcomes over volume. The ",[18,153,156],{"href":154,"rel":155},"https:\u002F\u002Fwolfsberg-group.org\u002Fresources\u002F202",[140],"2025 Part II statement"," covers moving to newer approaches responsibly: validate the change, balance model risk against financial crime risk, and keep the system explainable.",[11,159,160,161,166],{},"In the US, FinCEN's ",[18,162,165],{"href":163,"rel":164},"https:\u002F\u002Fwww.fincen.gov\u002Fsystem\u002Ffiles\u002F2025-10\u002FSAR-FAQs-October-2025.pdf",[140],"October 2025 SAR FAQs"," say monitoring parameters should be commensurate with the institution's money laundering and terrorist financing risk. The same FAQs clarify that a transaction near the USD 10,000 currency transaction report threshold is not, by itself, enough to require a SAR. A rule that alerts on proximity alone and nothing else will mostly generate noise.",[11,168,169],{},"So the regulators agree. A noisy program is not a cautious program. It is an uncalibrated one.",[49,171,173],{"id":172},"how-do-you-tune-transaction-monitoring-in-7-steps","How do you tune transaction monitoring in 7 steps?",[11,175,176],{},"Tune in a fixed order: measure, segment, set thresholds, add identifiers, rank, test, document. Skipping the first or the last two steps is how tuning turns into a finding.",[178,179,180,186,192,198,204,210,216],"ol",{},[33,181,182,185],{},[26,183,184],{},"Baseline current metrics."," Pull at least three months of alerts. For each rule, record volume, false positive rate, alert-to-case rate, SAR conversion rate, time to close, and backlog age.",[33,187,188,191],{},[26,189,190],{},"Segment customers by risk and behavior."," A payroll platform, a marketplace, and a remittance business have different normal activity. Group them by risk rating and expected pattern.",[33,193,194,197],{},[26,195,196],{},"Set thresholds from data."," Replace vendor defaults with values drawn from each segment's own distribution of amounts, counts, and velocity. Write down why each value was chosen.",[33,199,200,203],{},[26,201,202],{},"Add secondary identifiers."," A name hit alone shouldn't reach an analyst. Require date of birth, country, registration number, or wallet address to agree first.",[33,205,206,209],{},[26,207,208],{},"Rank alerts by risk score."," Combine customer risk, rule severity, amount, and counterparty exposure into one score, and work the queue from the top.",[33,211,212,215],{},[26,213,214],{},"Run below-the-line testing."," Sample activity just under each changed threshold and review it as if it had alerted. If real suspicious activity shows up, the change went too far.",[33,217,218,221],{},[26,219,220],{},"Document and schedule recalibration."," Record each change with its rationale, test results, and approver. Set the next review date, plus triggers like a new product, corridor, or segment.",[11,223,224,225,22],{},"The rule library itself is in ",[18,226,228],{"href":227},"\u002Fresources\u002Fmore\u002Ftransaction-monitoring-red-flags-stablecoin-payments","12 transaction monitoring red flags for stablecoin payments",[49,230,232],{"id":231},"which-tuning-levers-cut-false-positives-and-what-do-they-risk","Which tuning levers cut false positives, and what do they risk?",[11,234,235],{},"Six levers do most of the work: segmentation, peer group baselines, secondary identifier matching, deduplication, risk-based prioritization, and auto-close rules. Each one cuts noise and each one can hide something if applied without evidence.",[57,237,238,257],{},[60,239,240],{},[63,241,242,245,248,251,254],{},[66,243,244],{},"Lever",[66,246,247],{},"What changes",[66,249,250],{},"Benefit",[66,252,253],{},"Risk to manage",[66,255,256],{},"Evidence to keep",[76,258,259,276,293,310,327,344],{},[63,260,261,264,267,270,273],{},[81,262,263],{},"Customer segmentation",[81,265,266],{},"Thresholds differ by segment instead of one value for everyone",[81,268,269],{},"Rules stop firing on normal activity for high-volume segments",[81,271,272],{},"A bad actor placed in a lenient segment",[81,274,275],{},"Segment definitions and the assignment logic",[63,277,278,281,284,287,290],{},[81,279,280],{},"Peer group baselines",[81,282,283],{},"A customer is compared to similar customers, not to a fixed number",[81,285,286],{},"Catches outliers that a flat threshold misses",[81,288,289],{},"Peer groups drift as the business grows",[81,291,292],{},"Peer group membership and refresh dates",[63,294,295,298,301,304,307],{},[81,296,297],{},"Secondary identifier matching",[81,299,300],{},"Screening hits need date of birth, country, or ID to agree",[81,302,303],{},"Name-only sanctions noise drops sharply",[81,305,306],{},"Missing data on the record lets a real match through",[81,308,309],{},"Match logic and how missing fields are handled",[63,311,312,315,318,321,324],{},[81,313,314],{},"Alert deduplication",[81,316,317],{},"Several rules firing on the same activity become one alert",[81,319,320],{},"Analysts review each event once",[81,322,323],{},"Merged alerts lose the detail of which rules fired",[81,325,326],{},"The rule list attached to each merged alert",[63,328,329,332,335,338,341],{},[81,330,331],{},"Risk-based prioritization",[81,333,334],{},"Alerts are scored and worked highest first",[81,336,337],{},"High-risk alerts don't wait behind noise",[81,339,340],{},"Low-score alerts age out unreviewed",[81,342,343],{},"Score inputs, weights, and backlog age by band",[63,345,346,349,352,355,358],{},[81,347,348],{},"Auto-close rules",[81,350,351],{},"Narrow, explainable patterns close without a person",[81,353,354],{},"Analyst time goes to real decisions",[81,356,357],{},"A rule broader than intended clears true matches",[81,359,360],{},"Rule text, version, and a sampled QA of closures",[11,362,363,364,22],{},"Name matching drives most screening noise; cadence and matching choices are in ",[18,365,367],{"href":366},"\u002Fresources\u002Fmore\u002Fongoing-sanctions-screening-how-often-to-rescreen","ongoing sanctions screening: how often to rescreen",[49,369,371],{"id":370},"what-does-tuning-look-like-on-1000-alerts-a-week","What does tuning look like on 1,000 alerts a week?",[11,373,374],{},"Illustrative example: every number in this section is made up to show the mechanics, not drawn from any real program.",[11,376,377],{},"A payments company produces 1,000 alerts a week. 600 come from sanctions name screening and 400 from transaction rules.",[11,379,380,383],{},[26,381,382],{},"Deduplication."," Of the 400 transaction alerts, many are the same activity firing two or three rules (velocity, round amounts, and new counterparty, for one burst of payouts). Merging alerts on the same customer and time window turns 400 alerts into 250 events to review.",[11,385,386,389],{},[26,387,388],{},"Secondary identifiers."," Of the 600 screening alerts, most are common names where the listed person has a different date of birth and nationality. A documented rule closes hits where both identifiers are present and both disagree. That leaves 150 screening alerts where an identifier matches or is missing.",[11,391,392,395],{},[26,393,394],{},"Result."," Weekly reviews fall from 1,000 to 400. Say review still escalates 12 cases and 3 end in a SAR. SAR conversion moves from 0.3 percent of alerts to 0.75 percent, with the same cases found.",[11,397,398],{},"That last clause is the point. The team then samples the 450 screening closures and runs below-the-line tests on the merged transaction alerts. If the samples are clean for several cycles, the change holds. If one sample turns up a real case, the auto-close rule gets narrowed.",[49,400,402],{"id":401},"what-metrics-show-whether-tuning-is-working","What metrics show whether tuning is working?",[11,404,405],{},"Track six numbers per rule and per segment, every week: alert volume, false positive rate, backlog age, time to close, alert-to-case rate, and SAR conversion rate. Trends matter more than levels.",[11,407,408],{},"What warning signs look like:",[30,410,411,417,423,429,435],{},[33,412,413,416],{},[26,414,415],{},"False positives stay high on a rule that never produces a case."," The rule doesn't fit the business. Review it with evidence; don't delete it quietly.",[33,418,419,422],{},[26,420,421],{},"Backlog age keeps rising."," Alerts are piling up faster than people can review them. Real cases are now waiting.",[33,424,425,428],{},[26,426,427],{},"Time to close drops sharply with no tuning change."," Analysts may be clearing alerts without reading them. FCA guidance flags staff who always accept a customer's explanation at face value as poor practice.",[33,430,431,434],{},[26,432,433],{},"SAR conversion jumps after a threshold increase."," The change may have removed the borderline cases along with the noise. Check the below-the-line sample.",[33,436,437,440],{},[26,438,439],{},"Volume collapses for one segment."," Data may have stopped flowing to the rule. A silent feed failure looks exactly like successful tuning.",[11,442,443],{},"Report these monthly to the AML program owner. Tuning nobody above the analyst saw is hard to defend.",[49,445,447],{"id":446},"what-should-automation-close-and-where-must-a-human-decide","What should automation close, and where must a human decide?",[11,449,450],{},"Automation should close alerts that a written rule can explain with data on the record. People should decide anything where the outcome is a judgment, a report, or a blocked payment.",[11,452,453],{},"Reasonable to auto-close, with logging:",[30,455,456,459,462],{},[33,457,458],{},"Screening hits where date of birth and country both disagree with the listed person.",[33,460,461],{},"Duplicate alerts on an event already under review.",[33,463,464],{},"Known, documented patterns, such as a customer's scheduled payroll run that matches its declared activity and history.",[11,466,467],{},"Keep with a person:",[30,469,470,473,476,479],{},[33,471,472],{},"Possible true sanctions matches, including partial identifier matches and missing data.",[33,474,475],{},"Wallet addresses with direct or close exposure to sanctioned or illicit addresses.",[33,477,478],{},"Any alert that could lead to a SAR, an account exit, or a held payment.",[33,480,481,482,486],{},"Cases where Travel Rule data is missing or doesn't validate, which the ",[18,483,485],{"href":484},"\u002Fresources\u002Fmore\u002Ftravel-rule-workflow-hold-return-reject","Travel Rule workflow guide"," treats as a hold decision.",[11,488,489,493],{},[18,490,492],{"href":491},"\u002Fresources\u002Fmore\u002Fwhat-are-compliance-agents-in-fintech","Compliance agents"," can gather evidence and draft the narrative, but the decision stays with a named person.",[49,495,497],{"id":496},"what-are-the-common-mistakes-when-tuning-alerts","What are the common mistakes when tuning alerts?",[11,499,500],{},"The most common mistake is treating alert volume as the target. The others follow from it.",[30,502,503,509,515,521,527,533],{},[33,504,505,508],{},[26,506,507],{},"Tuning only to reduce volume."," If the goal is fewer alerts, raising every threshold works. It also blinds the program.",[33,510,511,514],{},[26,512,513],{},"No documented rationale."," A threshold nobody can explain is the poor practice the FCA describes. Write the reason when you set the value.",[33,516,517,520],{},[26,518,519],{},"Changing rules without testing."," Every change needs a before and after comparison and a below-the-line sample.",[33,522,523,526],{},[26,524,525],{},"Vendor tuning with no internal understanding."," A vendor can calibrate rules, but the firm answers for them. Someone in house must be able to explain each one.",[33,528,529,532],{},[26,530,531],{},"One threshold for every customer."," Flat thresholds fire constantly on high-volume customers and miss outliers among small ones.",[33,534,535,538],{},[26,536,537],{},"No recalibration date."," Rules tuned once drift as products and customers change.",[11,540,541,542,22],{},"Picking a vendor that exposes tuning and keeps a tuning history is covered in the ",[18,543,545],{"href":544},"\u002Fresources\u002Fmore\u002Fhow-to-choose-automated-risk-monitoring-vendor","risk monitoring vendor guide",[49,547,549],{"id":548},"how-does-blindpay-handle-flagged-transactions","How does BlindPay handle flagged transactions?",[11,551,552,553,557],{},"BlindPay runs transaction monitoring inside the payment flow, before money moves. A flagged payin or payout moves to ",[554,555,556],"code",{},"on_hold",", and the compliance team reviews it manually to determine whether it is a false positive.",[11,559,560,561,22],{},"If the flag can't be cleared internally, BlindPay sends a request for information asking about the relationship between the sender and the customer, the purpose of the transaction, and its expected outcome. If that request isn't answered within 24 hours, the transaction may be refunded to the sender. The process is described in ",[18,562,564],{"href":563},"\u002Fdocs\u002Fkb\u002Fon-hold-transactions","on-hold transactions",[49,566,568],{"id":567},"what-to-do-next","What to do next",[11,570,571],{},"Pull last quarter's alerts and compute the false positive rate per rule. Pick the two noisiest rules, segment their customers, and set new thresholds from data. Run a below-the-line sample before switching anything off, and write down the result. Then set the date for the next review.",[49,573,575],{"id":574},"sources-and-further-reading","Sources and further reading",[30,577,578,586,593,599,606],{},[33,579,580,581,585],{},"FCA, ",[18,582,584],{"href":138,"rel":583},[140],"Financial Crime Guide, FCG 3.2",", including transaction monitoring good and poor practice.",[33,587,588,589,22],{},"Wolfsberg Group, ",[18,590,592],{"href":148,"rel":591},[140],"Statement on Effective Monitoring for Suspicious Activity, Part I (2024)",[33,594,588,595,22],{},[18,596,598],{"href":154,"rel":597},[140],"Statement on Effective Monitoring for Suspicious Activity, Part II (2025)",[33,600,601,602,22],{},"FinCEN, ",[18,603,605],{"href":163,"rel":604},[140],"Frequently asked questions on SAR requirements (October 2025)",[33,607,601,608,22],{},[18,609,612],{"href":610,"rel":611},"https:\u002F\u002Fwww.law.cornell.edu\u002Fcfr\u002Ftext\u002F31\u002F1022.320",[140],"31 CFR 1022.320, SAR requirements for money services businesses",[11,614,615],{},[616,617,618],"em",{},"This article is general information, not legal advice.",{"title":620,"searchDepth":621,"depth":621,"links":622},"",2,[623,624,625,626,627,628,629,630,631,632,633],{"id":51,"depth":621,"text":52},{"id":128,"depth":621,"text":129},{"id":172,"depth":621,"text":173},{"id":231,"depth":621,"text":232},{"id":370,"depth":621,"text":371},{"id":401,"depth":621,"text":402},{"id":446,"depth":621,"text":447},{"id":496,"depth":621,"text":497},{"id":548,"depth":621,"text":549},{"id":567,"depth":621,"text":568},{"id":574,"depth":621,"text":575},"compliance","2026-10-03","Cut AML alert noise without losing real cases: a 7-step tuning process, the levers that work, the metrics to watch, and what automation should never close.","md",[639,642,645,648,651,654],{"q":640,"a":641},"What is a good false positive rate for AML transaction monitoring?","There is no regulatory target. False positive rates are high across the industry because rules are built to over-catch, so the useful question is whether the rate is falling while real cases still surface. Track it per rule, not program-wide. A rule that has produced zero cases in a year needs a documented review, not a quiet deletion.",{"q":643,"a":644},"What is below-the-line testing?","Below-the-line testing samples activity that falls just under a rule's threshold and reviews it as if it had alerted. If the sample contains suspicious activity, the threshold is too high. If it contains nothing over several cycles, there is room to raise it. It is the standard evidence that a tuning change reduced noise without hiding real risk.",{"q":646,"a":647},"Can automation close AML alerts without a human?","Yes, for narrow, explainable patterns that a documented rule can clear, such as a sanctions name hit where date of birth and country both differ from the listed person. Possible true matches, wallet exposure to sanctioned addresses, and anything that could lead to a SAR need a human decision. Every auto-close should log the rule, the data used, and the version.",{"q":649,"a":650},"What is SAR conversion rate?","SAR conversion rate is the share of alerts, or of escalated cases, that end in a suspicious activity report. It measures how much of the monitoring output is useful to law enforcement. A very low rate usually means noisy rules. A sudden jump can mean the opposite problem: thresholds raised so far that only obvious cases still alert.",{"q":652,"a":653},"How often should transaction monitoring rules be recalibrated?","At a set interval written into the AML policy and proportionate to risk, with higher-risk rules reviewed more often. Recalibrate sooner when something changes: a new product, corridor, customer segment, or a jump in volume. FinCEN expects monitoring parameters to match the institution's risk, so a schedule written into the AML policy is easier to defend than ad hoc changes.",{"q":655,"a":656},"Does reducing alerts increase regulatory risk?","Only if it is done without evidence. Cutting alerts by raising thresholds blindly can hide real activity, which examiners treat as a control failure. Cutting them by segmenting customers, adding secondary identifiers, and deduplicating, with below-the-line testing and a written rationale, usually improves the program. The UK FCA lists poorly calibrated, unexplained rules as poor practice.",{"name":658,"steps":659},"How to reduce false positives in automated transaction monitoring",[660,663,666,669,672,675,678],{"name":661,"text":662},"Baseline the current metrics","Pull at least three months of alerts and record, per rule, the alert volume, false positive rate, alert-to-case rate, SAR conversion rate, time to close, and backlog age. Tuning without a baseline can't be defended.",{"name":664,"text":665},"Segment customers by risk and behavior","Group customers by risk rating and by expected activity, such as payroll platforms, marketplaces, and remittance businesses, so each segment gets thresholds that fit its normal pattern.",{"name":667,"text":668},"Set thresholds from data","Replace vendor defaults with thresholds derived from each segment's own distribution of amounts, counts, and velocity, and write down why each value was chosen.",{"name":670,"text":671},"Add secondary identifiers","Require date of birth, country, registration number, or wallet address to agree before a screening hit becomes an alert, so name-only matches stop reaching analysts.",{"name":673,"text":674},"Rank alerts by risk score","Combine customer risk, rule severity, amount, and counterparty exposure into one score, and work the queue from the top so high-risk alerts never wait behind noise.",{"name":676,"text":677},"Run below-the-line testing","Sample activity just under each changed threshold and review it as if it had alerted. If real suspicious activity appears in the sample, the threshold went too far.",{"name":679,"text":680},"Document and schedule recalibration","Record every change with its rationale, test results, and approver, and set a recalibration date proportionate to risk, plus triggers such as a new product or corridor.",false,{"author":683},"BlindPay Team",true,"\u002Fresources\u002Fmore\u002Freduce-false-positives-transaction-monitoring","---\ntitle: \"How to reduce false positives in transaction monitoring without missing real risk\"\nseoTitle: \"How to reduce false positives in AML transaction monitoring\"\ndescription: \"Cut AML alert noise without losing real cases: a 7-step tuning process, the levers that work, the metrics to watch, and what automation should never close.\"\ndate: \"2026-10-03\"\nupdated: \"2026-10-03\"\ncategory: \"compliance\"\nauthor: \"BlindPay Team\"\nhowto:\n  name: \"How to reduce false positives in automated transaction monitoring\"\n  steps:\n    - name: \"Baseline the current metrics\"\n      text: \"Pull at least three months of alerts and record, per rule, the alert volume, false positive rate, alert-to-case rate, SAR conversion rate, time to close, and backlog age. Tuning without a baseline can't be defended.\"\n    - name: \"Segment customers by risk and behavior\"\n      text: \"Group customers by risk rating and by expected activity, such as payroll platforms, marketplaces, and remittance businesses, so each segment gets thresholds that fit its normal pattern.\"\n    - name: \"Set thresholds from data\"\n      text: \"Replace vendor defaults with thresholds derived from each segment's own distribution of amounts, counts, and velocity, and write down why each value was chosen.\"\n    - name: \"Add secondary identifiers\"\n      text: \"Require date of birth, country, registration number, or wallet address to agree before a screening hit becomes an alert, so name-only matches stop reaching analysts.\"\n    - name: \"Rank alerts by risk score\"\n      text: \"Combine customer risk, rule severity, amount, and counterparty exposure into one score, and work the queue from the top so high-risk alerts never wait behind noise.\"\n    - name: \"Run below-the-line testing\"\n      text: \"Sample activity just under each changed threshold and review it as if it had alerted. If real suspicious activity appears in the sample, the threshold went too far.\"\n    - name: \"Document and schedule recalibration\"\n      text: \"Record every change with its rationale, test results, and approver, and set a recalibration date proportionate to risk, plus triggers such as a new product or corridor.\"\nfaq:\n  - q: \"What is a good false positive rate for AML transaction monitoring?\"\n    a: \"There is no regulatory target. False positive rates are high across the industry because rules are built to over-catch, so the useful question is whether the rate is falling while real cases still surface. Track it per rule, not program-wide. A rule that has produced zero cases in a year needs a documented review, not a quiet deletion.\"\n  - q: \"What is below-the-line testing?\"\n    a: \"Below-the-line testing samples activity that falls just under a rule's threshold and reviews it as if it had alerted. If the sample contains suspicious activity, the threshold is too high. If it contains nothing over several cycles, there is room to raise it. It is the standard evidence that a tuning change reduced noise without hiding real risk.\"\n  - q: \"Can automation close AML alerts without a human?\"\n    a: \"Yes, for narrow, explainable patterns that a documented rule can clear, such as a sanctions name hit where date of birth and country both differ from the listed person. Possible true matches, wallet exposure to sanctioned addresses, and anything that could lead to a SAR need a human decision. Every auto-close should log the rule, the data used, and the version.\"\n  - q: \"What is SAR conversion rate?\"\n    a: \"SAR conversion rate is the share of alerts, or of escalated cases, that end in a suspicious activity report. It measures how much of the monitoring output is useful to law enforcement. A very low rate usually means noisy rules. A sudden jump can mean the opposite problem: thresholds raised so far that only obvious cases still alert.\"\n  - q: \"How often should transaction monitoring rules be recalibrated?\"\n    a: \"At a set interval written into the AML policy and proportionate to risk, with higher-risk rules reviewed more often. Recalibrate sooner when something changes: a new product, corridor, customer segment, or a jump in volume. FinCEN expects monitoring parameters to match the institution's risk, so a schedule written into the AML policy is easier to defend than ad hoc changes.\"\n  - q: \"Does reducing alerts increase regulatory risk?\"\n    a: \"Only if it is done without evidence. Cutting alerts by raising thresholds blindly can hide real activity, which examiners treat as a control failure. Cutting them by segmenting customers, adding secondary identifiers, and deduplicating, with below-the-line testing and a written rationale, usually improves the program. The UK FCA lists poorly calibrated, unexplained rules as poor practice.\"\n---\n\nTo reduce false positives in AML transaction monitoring, segment customers by risk and behavior, set thresholds from your own data, add secondary identifiers to screening matches, deduplicate alerts, and rank them by risk score. Then prove nothing real was lost with below-the-line testing, and document every change. Fewer alerts is the result, not the goal.\n\nThis article is general information, not legal advice. It assumes a monitoring program already exists; if you are still mapping the parts, start with [what automated risk monitoring is](\u002Fresources\u002Fmore\u002Fwhat-is-automated-risk-monitoring-fintech).\n\n**Key takeaways**\n\n- A false positive is an alert that review closes as not suspicious. Most programs produce far more of these than real cases.\n- High alert volume is a control weakness, not a safety margin. Real cases wait in the same queue as the noise.\n- Tune with data, per customer segment, and test below the line before and after every change.\n- Automation can close narrow, explainable patterns. Possible true matches and SAR decisions stay with people.\n- Keep the rationale, the test results, and the approver for every change. That record is what an examiner reads.\n\n## What counts as a false positive in risk monitoring?\n\nA false positive is an alert that a reviewer closes because the activity turned out to be normal. A true positive is an alert that review confirms as suspicious or as a real sanctions match.\n\n| Term | Definition | What it tells you |\n| --- | --- | --- |\n| False positive | An alert closed after review as not suspicious | How much analyst time goes to noise |\n| True positive | An alert confirmed as suspicious activity or a real list match | Whether the rule catches what it was built for |\n| Alert-to-case rate | Share of alerts escalated into a full investigation case | How often an alert needs more than a first look |\n| SAR conversion rate | Share of alerts, or of cases, that end in a suspicious activity report (SAR) | How much monitoring output is useful to law enforcement |\n\nMeasure each one per rule and per segment. A program-wide rate hides the two rules that make most of the noise.\n\n## Why is high alert volume a control weakness?\n\nHigh alert volume is a weakness because analysts can't give every alert real attention, so real cases get the same rushed review as the noise. It also signals that the rules don't fit the business, which is what regulators look for first.\n\nThe UK Financial Conduct Authority (FCA) says this directly in its [Financial Crime Guide](https:\u002F\u002Fhandbook.fca.org.uk\u002Fhandbook\u002FFCG\u002F3\u002F2.html). Section FCG 3.2.5A lists, as poor practice, a weak control framework around automated monitoring, threshold-based rules used where they don't suit the activity, and poorly calibrated rule systems where the firm struggles to explain why a particular rule exists. Good practice in the same section includes a holistic view of customer behavior and monitoring at several levels of aggregation.\n\nThe Wolfsberg Group, an association of global banks that publishes financial crime standards, made the same point from the reporting side. Its [2024 Statement on Effective Monitoring for Suspicious Activity](https:\u002F\u002Fwolfsberg-group.org\u002Fresources\u002F168) argues that the growing volume of SARs isn't producing a proportionate gain in effective outcomes, and pushes programs toward outcomes over volume. The [2025 Part II statement](https:\u002F\u002Fwolfsberg-group.org\u002Fresources\u002F202) covers moving to newer approaches responsibly: validate the change, balance model risk against financial crime risk, and keep the system explainable.\n\nIn the US, FinCEN's [October 2025 SAR FAQs](https:\u002F\u002Fwww.fincen.gov\u002Fsystem\u002Ffiles\u002F2025-10\u002FSAR-FAQs-October-2025.pdf) say monitoring parameters should be commensurate with the institution's money laundering and terrorist financing risk. The same FAQs clarify that a transaction near the USD 10,000 currency transaction report threshold is not, by itself, enough to require a SAR. A rule that alerts on proximity alone and nothing else will mostly generate noise.\n\nSo the regulators agree. A noisy program is not a cautious program. It is an uncalibrated one.\n\n## How do you tune transaction monitoring in 7 steps?\n\nTune in a fixed order: measure, segment, set thresholds, add identifiers, rank, test, document. Skipping the first or the last two steps is how tuning turns into a finding.\n\n1. **Baseline current metrics.** Pull at least three months of alerts. For each rule, record volume, false positive rate, alert-to-case rate, SAR conversion rate, time to close, and backlog age.\n2. **Segment customers by risk and behavior.** A payroll platform, a marketplace, and a remittance business have different normal activity. Group them by risk rating and expected pattern.\n3. **Set thresholds from data.** Replace vendor defaults with values drawn from each segment's own distribution of amounts, counts, and velocity. Write down why each value was chosen.\n4. **Add secondary identifiers.** A name hit alone shouldn't reach an analyst. Require date of birth, country, registration number, or wallet address to agree first.\n5. **Rank alerts by risk score.** Combine customer risk, rule severity, amount, and counterparty exposure into one score, and work the queue from the top.\n6. **Run below-the-line testing.** Sample activity just under each changed threshold and review it as if it had alerted. If real suspicious activity shows up, the change went too far.\n7. **Document and schedule recalibration.** Record each change with its rationale, test results, and approver. Set the next review date, plus triggers like a new product, corridor, or segment.\n\nThe rule library itself is in [12 transaction monitoring red flags for stablecoin payments](\u002Fresources\u002Fmore\u002Ftransaction-monitoring-red-flags-stablecoin-payments).\n\n## Which tuning levers cut false positives, and what do they risk?\n\nSix levers do most of the work: segmentation, peer group baselines, secondary identifier matching, deduplication, risk-based prioritization, and auto-close rules. Each one cuts noise and each one can hide something if applied without evidence.\n\n| Lever | What changes | Benefit | Risk to manage | Evidence to keep |\n| --- | --- | --- | --- | --- |\n| Customer segmentation | Thresholds differ by segment instead of one value for everyone | Rules stop firing on normal activity for high-volume segments | A bad actor placed in a lenient segment | Segment definitions and the assignment logic |\n| Peer group baselines | A customer is compared to similar customers, not to a fixed number | Catches outliers that a flat threshold misses | Peer groups drift as the business grows | Peer group membership and refresh dates |\n| Secondary identifier matching | Screening hits need date of birth, country, or ID to agree | Name-only sanctions noise drops sharply | Missing data on the record lets a real match through | Match logic and how missing fields are handled |\n| Alert deduplication | Several rules firing on the same activity become one alert | Analysts review each event once | Merged alerts lose the detail of which rules fired | The rule list attached to each merged alert |\n| Risk-based prioritization | Alerts are scored and worked highest first | High-risk alerts don't wait behind noise | Low-score alerts age out unreviewed | Score inputs, weights, and backlog age by band |\n| Auto-close rules | Narrow, explainable patterns close without a person | Analyst time goes to real decisions | A rule broader than intended clears true matches | Rule text, version, and a sampled QA of closures |\n\nName matching drives most screening noise; cadence and matching choices are in [ongoing sanctions screening: how often to rescreen](\u002Fresources\u002Fmore\u002Fongoing-sanctions-screening-how-often-to-rescreen).\n\n## What does tuning look like on 1,000 alerts a week?\n\nIllustrative example: every number in this section is made up to show the mechanics, not drawn from any real program.\n\nA payments company produces 1,000 alerts a week. 600 come from sanctions name screening and 400 from transaction rules.\n\n**Deduplication.** Of the 400 transaction alerts, many are the same activity firing two or three rules (velocity, round amounts, and new counterparty, for one burst of payouts). Merging alerts on the same customer and time window turns 400 alerts into 250 events to review.\n\n**Secondary identifiers.** Of the 600 screening alerts, most are common names where the listed person has a different date of birth and nationality. A documented rule closes hits where both identifiers are present and both disagree. That leaves 150 screening alerts where an identifier matches or is missing.\n\n**Result.** Weekly reviews fall from 1,000 to 400. Say review still escalates 12 cases and 3 end in a SAR. SAR conversion moves from 0.3 percent of alerts to 0.75 percent, with the same cases found.\n\nThat last clause is the point. The team then samples the 450 screening closures and runs below-the-line tests on the merged transaction alerts. If the samples are clean for several cycles, the change holds. If one sample turns up a real case, the auto-close rule gets narrowed.\n\n## What metrics show whether tuning is working?\n\nTrack six numbers per rule and per segment, every week: alert volume, false positive rate, backlog age, time to close, alert-to-case rate, and SAR conversion rate. Trends matter more than levels.\n\nWhat warning signs look like:\n\n- **False positives stay high on a rule that never produces a case.** The rule doesn't fit the business. Review it with evidence; don't delete it quietly.\n- **Backlog age keeps rising.** Alerts are piling up faster than people can review them. Real cases are now waiting.\n- **Time to close drops sharply with no tuning change.** Analysts may be clearing alerts without reading them. FCA guidance flags staff who always accept a customer's explanation at face value as poor practice.\n- **SAR conversion jumps after a threshold increase.** The change may have removed the borderline cases along with the noise. Check the below-the-line sample.\n- **Volume collapses for one segment.** Data may have stopped flowing to the rule. A silent feed failure looks exactly like successful tuning.\n\nReport these monthly to the AML program owner. Tuning nobody above the analyst saw is hard to defend.\n\n## What should automation close, and where must a human decide?\n\nAutomation should close alerts that a written rule can explain with data on the record. People should decide anything where the outcome is a judgment, a report, or a blocked payment.\n\nReasonable to auto-close, with logging:\n\n- Screening hits where date of birth and country both disagree with the listed person.\n- Duplicate alerts on an event already under review.\n- Known, documented patterns, such as a customer's scheduled payroll run that matches its declared activity and history.\n\nKeep with a person:\n\n- Possible true sanctions matches, including partial identifier matches and missing data.\n- Wallet addresses with direct or close exposure to sanctioned or illicit addresses.\n- Any alert that could lead to a SAR, an account exit, or a held payment.\n- Cases where Travel Rule data is missing or doesn't validate, which the [Travel Rule workflow guide](\u002Fresources\u002Fmore\u002Ftravel-rule-workflow-hold-return-reject) treats as a hold decision.\n\n[Compliance agents](\u002Fresources\u002Fmore\u002Fwhat-are-compliance-agents-in-fintech) can gather evidence and draft the narrative, but the decision stays with a named person.\n\n## What are the common mistakes when tuning alerts?\n\nThe most common mistake is treating alert volume as the target. The others follow from it.\n\n- **Tuning only to reduce volume.** If the goal is fewer alerts, raising every threshold works. It also blinds the program.\n- **No documented rationale.** A threshold nobody can explain is the poor practice the FCA describes. Write the reason when you set the value.\n- **Changing rules without testing.** Every change needs a before and after comparison and a below-the-line sample.\n- **Vendor tuning with no internal understanding.** A vendor can calibrate rules, but the firm answers for them. Someone in house must be able to explain each one.\n- **One threshold for every customer.** Flat thresholds fire constantly on high-volume customers and miss outliers among small ones.\n- **No recalibration date.** Rules tuned once drift as products and customers change.\n\nPicking a vendor that exposes tuning and keeps a tuning history is covered in the [risk monitoring vendor guide](\u002Fresources\u002Fmore\u002Fhow-to-choose-automated-risk-monitoring-vendor).\n\n## How does BlindPay handle flagged transactions?\n\nBlindPay runs transaction monitoring inside the payment flow, before money moves. A flagged payin or payout moves to `on_hold`, and the compliance team reviews it manually to determine whether it is a false positive.\n\nIf the flag can't be cleared internally, BlindPay sends a request for information asking about the relationship between the sender and the customer, the purpose of the transaction, and its expected outcome. If that request isn't answered within 24 hours, the transaction may be refunded to the sender. The process is described in [on-hold transactions](\u002Fdocs\u002Fkb\u002Fon-hold-transactions).\n\n## What to do next\n\nPull last quarter's alerts and compute the false positive rate per rule. Pick the two noisiest rules, segment their customers, and set new thresholds from data. Run a below-the-line sample before switching anything off, and write down the result. Then set the date for the next review.\n\n## Sources and further reading\n\n- FCA, [Financial Crime Guide, FCG 3.2](https:\u002F\u002Fhandbook.fca.org.uk\u002Fhandbook\u002FFCG\u002F3\u002F2.html), including transaction monitoring good and poor practice.\n- Wolfsberg Group, [Statement on Effective Monitoring for Suspicious Activity, Part I (2024)](https:\u002F\u002Fwolfsberg-group.org\u002Fresources\u002F168).\n- Wolfsberg Group, [Statement on Effective Monitoring for Suspicious Activity, Part II (2025)](https:\u002F\u002Fwolfsberg-group.org\u002Fresources\u002F202).\n- FinCEN, [Frequently asked questions on SAR requirements (October 2025)](https:\u002F\u002Fwww.fincen.gov\u002Fsystem\u002Ffiles\u002F2025-10\u002FSAR-FAQs-October-2025.pdf).\n- FinCEN, [31 CFR 1022.320, SAR requirements for money services businesses](https:\u002F\u002Fwww.law.cornell.edu\u002Fcfr\u002Ftext\u002F31\u002F1022.320).\n\n*This article is general information, not legal advice.*\n",{"title":5,"description":636},"How to reduce false positives in AML transaction monitoring","resources\u002Fmore\u002Freduce-false-positives-transaction-monitoring","EWpAImKrFSk0Z9tvDxg5PVUWLJr_5BAdCh-yv3A-UTw",[692,696,700,704,708,712,716,720,724,728,732,735,736,740,743,747,751,755,759,763,767,770,773,777,780,784,788,791,795,799],{"path":693,"title":694,"description":695},"\u002Fresources\u002Fmore\u002Faml-audit-readiness-risk-monitoring","AML audit readiness: what regulators ask for and how to prove your risk monitoring works","The evidence examiners expect from automated risk monitoring: a 10-item evidence table, good vs poor practice, SAR timelines, RFIs, and a 30-day plan.",{"path":697,"title":698,"description":699},"\u002Fresources\u002Fmore\u002Fare-blockchain-payments-legal","Are blockchain payments legal? Rules in the US, EU, UK, Brazil, and Mexico","Blockchain payments are legal for businesses in the US, EU, UK, Brazil, and Mexico, under different rules. What each country regulates, as of October 2026.",{"path":701,"title":702,"description":703},"\u002Fresources\u002Fmore\u002Fare-stablecoin-payments-reversible","Are stablecoin payments reversible? Finality, custody, and fraud explained","Stablecoin transfers settle final in minutes and cannot be reversed. That finality proves custody at every step, but it also opens a fraud gap on the fiat side of the payment.",{"path":705,"title":706,"description":707},"\u002Fresources\u002Fmore\u002Fautomated-kyc-kyb-vs-manual-onboarding","Automated KYC\u002FKYB vs. manual onboarding: what actually changes","A side-by-side comparison of automated and manual KYC\u002FKYB for fintechs: onboarding time, false-positive rates, cost per verification, scaling across jurisdictions, and audit-trail quality, plus the cases where a human reviewer is still required.",{"path":709,"title":710,"description":711},"\u002Fresources\u002Fmore\u002Fbuild-vs-buy-automated-risk-monitoring","Build vs. buy automated risk monitoring: a decision framework and 15 provider questions","Build, buy point solutions, or use an integrated provider? Compare three ways to run automated risk monitoring, who stays responsible, and 15 questions.",{"path":713,"title":714,"description":715},"\u002Fresources\u002Fmore\u002Fcompliance-agents-cross-border-stablecoin-payments","Compliance agents for cross-border stablecoin payments: a global regulatory guide","How compliance agents apply FinCEN, MiCA, FCA, MAS, and Banco Central do Brasil rules to cross-border stablecoin payments: jurisdiction table, the FATF Travel Rule, multi-list sanctions screening, the four components of a compliant program, and questions to ask a compliance provider.",{"path":717,"title":718,"description":719},"\u002Fresources\u002Fmore\u002Fcrypto-wallet-compliance-checklist","Crypto wallet compliance checklist: KYC, KYT, and Travel Rule","The compliance that comes with crypto wallets and stablecoin payments: KYC and KYB, KYT, the Travel Rule, address screening, MSB rules, and 15 checks.",{"path":721,"title":722,"description":723},"\u002Fresources\u002Fmore\u002Fdirect-vs-indirect-stablecoin-exchange","Direct vs indirect stablecoin exchange: who holds the stablecoin, and who carries compliance","In direct exchange, both parties hold stablecoins and own compliance. In indirect exchange, a provider settles in stablecoins behind a normal bank payment.",{"path":725,"title":726,"description":727},"\u002Fresources\u002Fmore\u002Fdo-merchants-need-a-license-to-accept-stablecoins","Do merchants need a license to accept stablecoin payments? KYC, KYB, and compliance explained","Usually no: the license sits with the provider that moves the funds. What merchants still owe on KYB, sanctions, tax, and records in the US, EU, Brazil.",{"path":729,"title":730,"description":731},"\u002Fresources\u002Fmore\u002Fhow-to-automate-kyc-kyb-stablecoin-payments","How to automate KYC and KYB for stablecoin payments","A developer guide to automated KYC and KYB for stablecoin payment flows: how verification runs inside a payment API, step-by-step workflows for individuals and businesses, jurisdiction requirements for the US, EU, UK, Singapore, and Brazil, and what to check before settlement.",{"path":544,"title":733,"description":734},"How to choose an automated risk monitoring vendor for a fintech startup","A buyer's guide to automated risk monitoring vendors for early-stage fintechs: the five criteria that matter (regulatory coverage, integration effort, false-positive rate, pricing model, audit output), the question to ask a vendor on each, a checklist table, and what it costs.",{"path":685,"title":5,"description":636},{"path":737,"title":738,"description":739},"\u002Fresources\u002Fmore\u002Fmica-stablecoin-rules-explained","MiCA stablecoin rules explained for payment companies","What MiCA means if your business uses stablecoins in the EU: EMTs vs ARTs, issuer requirements, why USDC is compliant and USDT was delisted, and a practical checklist.",{"path":366,"title":741,"description":742},"Ongoing sanctions screening: how often to rescreen and what to screen","How often to rescreen customers against sanctions lists, what to screen beyond names, and a cadence that holds up under OFAC strict liability.",{"path":744,"title":745,"description":746},"\u002Fresources\u002Fmore\u002Fpsav-brazil-explained","PSAV in Brazil: the Central Bank's virtual asset license explained","PSAV is Brazil's authorization for virtual asset service providers, created by BCB Resolutions 519, 520, and 521 under Law 14.478\u002F2022. What it requires and who needs it.",{"path":748,"title":749,"description":750},"\u002Fresources\u002Fmore\u002Freal-time-transaction-monitoring-stablecoin-payments","Real-time transaction monitoring for cross-border stablecoin payments","Why stablecoin cross-border flows need different monitoring than wires: the signals that get scored (wallet address risk, velocity, corridor risk, on\u002Foff-ramp counterparties), real-time vs. batch monitoring, and a worked example of a flagged pattern from alert to decision.",{"path":752,"title":753,"description":754},"\u002Fresources\u002Fmore\u002Fstablecoin-card-issuing-compliance","Stablecoin card issuing compliance: KYC, KYB, and regulatory coverage explained","What compliance stablecoin card issuing requires: KYC vs. KYB, who is responsible for what, how rules differ in the US, EU, UK, and Latin America, and ongoing monitoring.",{"path":756,"title":757,"description":758},"\u002Fresources\u002Fmore\u002Fstablecoin-off-ramp-limits","Stablecoin off-ramp limits: per-transaction, daily, and monthly caps explained","Why off-ramps cap how much you can convert per transaction, day, and month, how the caps map to KYC and KYB tiers, and the documents that raise them.",{"path":760,"title":761,"description":762},"\u002Fresources\u002Fmore\u002Fstablecoin-regulation-tracker-2026","Stablecoin regulation in 2026: MiCA, the GENIUS Act, Brazil, and Japan","Where stablecoin regulation stands in 2026: MiCA in the EU, the GENIUS Act in the US, Brazil's VASP regime, and Japan's issuer rules, compared for payment businesses.",{"path":764,"title":765,"description":766},"\u002Fresources\u002Fmore\u002Fgenius-act-for-businesses","The GENIUS Act explained for businesses that use stablecoins","What the GENIUS Act means if your business sends, receives, or holds stablecoins: who it regulates, the dates that matter, and what to do before 2027.",{"path":484,"title":768,"description":769},"The Travel Rule in an automated workflow: what to collect, when to hold, when to return","How to automate Travel Rule compliance for stablecoin transfers: what data to collect, the checks before release, and when to hold, reject, or return.",{"path":227,"title":771,"description":772},"Transaction monitoring red flags for stablecoin payments: 12 rules to automate","The 12 red flags automated transaction monitoring should catch in stablecoin and cross-border payments, with rule logic, actions, and the data each needs.",{"path":774,"title":775,"description":776},"\u002Fresources\u002Fmore\u002Fvirtual-account-requirements-kyc-kyb","Virtual account requirements: KYC, KYB, and what the bank reviews before it says yes","What you need to open a virtual account: KYC or KYB, the extra fields and source of funds documents the bank reviews, who owns each step, and timelines.",{"path":491,"title":778,"description":779},"What are compliance agents in fintech? How they work and what they do for payments","Compliance agents are autonomous software components that run KYC, KYB, sanctions screening, and transaction monitoring inside a payment flow, then document every decision. How they work, what they do for payments, how they differ from traditional compliance software, and how BlindPay embeds them in its API.",{"path":781,"title":782,"description":783},"\u002Fresources\u002Fmore\u002Fwhat-is-kyb","What is KYB? Know Your Business verification explained","KYB verifies a company's legal existence, ownership, and control before it can transact. What it checks, who counts as a beneficial owner, and how it differs from KYC.",{"path":785,"title":786,"description":787},"\u002Fresources\u002Fmore\u002Fwhat-is-a-vasp","What is a VASP? Virtual asset service provider explained","A VASP is any business that exchanges, transfers, or custodies virtual assets like stablecoins for customers. FATF's definition and what it requires in practice.",{"path":20,"title":789,"description":790},"What is automated risk monitoring in fintech?","A reference explainer on automated risk monitoring for fintechs: the four components (KYC\u002FKYB, transaction monitoring, sanctions and watchlist screening, compliance automation), what each one flags, a manual vs. automated comparison, and what FinCEN, FATF, and OFAC actually require.",{"path":792,"title":793,"description":794},"\u002Fresources\u002Fmore\u002Ftravel-rule-stablecoin-off-ramps","What is the travel rule for stablecoin off-ramps? Thresholds, data, and failed checks","The travel rule makes off-ramps pass sender and receiver data with transfers. Thresholds by country, required data, and what happens when checks fail.",{"path":796,"title":797,"description":798},"\u002Fresources\u002Fmore\u002Fcrypto-on-ramp-compliance-who-owns-what","Who owns compliance when you integrate a crypto on-ramp API? KYC, KYB, KYT, and holds","An on-ramp API splits compliance between the provider and you. Who runs KYC, KYB, KYT, sanctions, and the travel rule, and what stays on your side.",{"path":800,"title":801,"description":802},"\u002Fresources\u002Fmore\u002Fsource-of-funds-crypto-off-ramps","Why do crypto off-ramps ask for source of funds? Documents, triggers, and on-chain proof","Why off-ramps ask where your stablecoins came from, how source of funds differs from source of wealth, what triggers a request, and which documents pass.",1791301931503]