Financial Transaction Compliance Classifier

The transaction block supplies the type, amount, and flags like structuring_suspected, while the customer block adds jurisdiction, kyc_verified status, risk indicators, and normal_activity_patterns for behavioral comparison.

Type and amount pairs assign priority and paperwork under a first hit policy: a 'cash_deposit' over 10000 is 'high_priority' with a 'CTR', an 'international_wire' over 3000 maps to 'FBAR', a 'securities_trade' over 5000 to 'SEC_REPORT', a 'crypto_transaction' over 3000 to a 'high_priority' 'CRYPTO_SAR', and any 'structured_deposit' straight to 'SAR' with no amount test. Domestic wires over 10000 file a 'WIRE_REPORT' at 'low_priority', and everything else falls to 'standard' and 'STANDARD'.

The 10000 cash threshold is the genuine Bank Secrecy Act trigger for a Currency Transaction Report, and routing suspected structured deposits directly to a SAR reflects that structuring is itself reportable regardless of amount. The 3000 and 5000 thresholds on wires, securities, and crypto are tighter than statutory minimums, a conservative screening choice that surfaces activity for review before it reaches mandatory reporting levels.

Reporting mechanics come from crossing customer.jurisdiction with the classification.report_type: a 'US' 'CTR' allows 15 days on 'FinCEN Form 112' with a jurisdiction score of 15, a 'US' 'SAR' 30 days on 'FinCEN Form 111', 'EU' cases get 10 days on the 'EU Suspicious Transaction Report', 'UK' cases 7 days on an 'NCA SAR', and the default grants 30 days on a 'Standard Reporting Form' with the lowest score of 5.

The US rows match actual FinCEN practice: Form 112 is the Currency Transaction Report with a 15-day filing window, and Form 111 is the Suspicious Activity Report, generally due within 30 days of detection. UK suspicious activity reports really are filed with the National Crime Agency; the day counts on the EU row and the jurisdiction scores are the template's own risk weighting rather than a single statutory figure.

Additive scoring builds total_risk_score from five parts: amount_score steps 5/10/15/25 at the 5000, 10000, and 50000 marks, priority_score gives 'high_priority' 25 points, customer_score adds 20 for a high_risk customer, transaction_history_score adds up to 20 as suspicious_activity_count grows, and the jurisdiction score from the previous table completes the sum. Keeping each factor a separate key makes the final score auditable term by term.

Review necessity resolves from score and priority together: a total_risk_score over 75 combined with 'high_priority' demands immediate review, over 60 requires compliance review at any priority, and scores in the [40..60] band only escalate when the priority is high. The two remaining rows return requires_review false with standard monitoring messaging.

Two-dimensional cutoffs like this are how monitoring teams triage alert queues: pure score thresholds either flood analysts or miss context, so priority acts as a tiebreaker in the ambiguous middle band. The 40/60/75 boundaries are tuning parameters an institution would calibrate against its own alert volumes, not values fixed by regulation.

Because the hit policy is collect, every matching condition appends a flag object to compliance.flags: 'KYC_INCOMPLETE' when transaction.amount > 10000 and customer.kyc_verified != true, 'HIGH_RISK_JURISDICTION' for amounts over 5000 touching a high_risk_country, 'PATTERN_ALERT' when prior suspicious_activity_count exists on transactions over 3000, 'STRUCTURING' whenever structuring_suspected is true, and 'UNUSUAL_ACTIVITY' for amounts over 50000 outside customer.normal_activity_patterns.

These mirror the red flags AML programs actually monitor: unverified identity on large transactions, exposure to high-risk jurisdictions, repeat suspicious behavior, structuring below reporting thresholds, and out-of-pattern activity are all staples of transaction monitoring typologies. Emitting typed flags with descriptions, rather than one boolean, gives case management systems the detail needed to open targeted investigations.

Deadlines and urgency are finalized here: reporting_deadline adds reporting.days_to_report (as seconds, days * 86400) to the transaction date, requires_immediate_filing fires when review is required or flags coincide with 'high_priority', and reporting_status grades the case as 'urgent_filing_required', 'filing_required', or 'standard_reporting'. The report_instructions string names the form and window, such as 'File ' + reporting.form_name + ' within 24 hours', so compliance staff receive an actionable directive.