Your fintech just onboarded a client that processes cross-border payments for electronics importers. Your AML officer flags unusual pricing patterns. Your fraud team sees legitimate trade documentation. Your compliance lead asks: where exactly should TBML detection sit in your stack?
This isn't an academic question. Trade-Based Money Laundering exploits the legitimate flow of goods and payments. Your detection logic needs to be where you can see both the financial transaction and the underlying trade relationship. Get the placement wrong, and you'll either miss the scheme entirely or drown your operations team in false positives.
The Decision You're Facing
You're choosing between three architectural approaches to TBML and TBTF detection:
- Transaction-layer monitoring, flag suspicious payments as they move through your rails.
- Entity-layer surveillance, assess customer risk profiles and trading patterns over time.
- Hybrid architecture, combine real-time transaction signals with entity-level context.
Each path has different resource requirements, detection capabilities, and regulatory implications. Your National Risk Assessment should inform this choice, but most fintechs don't have access to sanitized NRA outputs when they're building their first TBML controls.
Key Factors That Affect Your Choice
Your customer base determines exposure. If you're processing payments for importers and exporters, you're in the direct path of TBML schemes. If you're handling domestic card payments with occasional international wires, your TBML risk is lower than your structuring risk.
Your data access shapes what you can detect. Transaction monitoring sees payment amounts, originator/beneficiary details, and timing. Entity surveillance sees trading history, beneficial ownership, corporate structures, and cross-border relationships. TBML schemes often exploit trade sectors across multiple jurisdictions, so you need visibility into the supply chain, not just the wire transfer.
Your regulatory obligations set the floor. FATF Recommendation 10 requires customer due diligence that assesses risks posed by potential and current customers. That's entity-layer work. But effective TBML detection also requires transaction-level signals, because criminals exploit both new supply chains (entity risk) and payment manipulation (transaction risk).
Your operational capacity determines sustainability. A transaction-only approach generates high alert volumes if you don't have entity context. An entity-only approach misses real-time manipulation if you're not monitoring payment patterns. Hybrid architectures require more sophisticated tooling but produce more actionable alerts.
Path A: Transaction-Layer Monitoring
Choose this path if you're a payment processor with limited visibility into underlying trade relationships, or if you're building your first TBML controls and need to establish baseline detection quickly.
When it works: You process payments for clients whose primary business isn't import/export. Your KYC data doesn't include detailed trade documentation. Your alert volume tolerance is high enough to handle false positives from pricing anomalies you can't contextualize.
Implementation approach: Build rules that flag:
- Payments inconsistent with declared commodity values.
- Round-number transfers that don't match typical trade pricing.
- Rapid sequences of payments to the same beneficiary across multiple originators.
- Payment descriptions that don't match the customer's stated business activity.
Reference FATF Recommendation 15: assess how criminals might exploit new payment technologies before you launch them. If you're adding instant cross-border rails, model how TBML actors could use speed to move value before you have time to investigate.
Regulatory coverage: This satisfies your obligation to monitor transactions for suspicious activity and file Suspicious Activity Reports when appropriate. It doesn't fully address Recommendation 10's requirement to assess customer risk, which requires entity-level analysis.
Operational reality: You'll file more SARs per true positive than a hybrid approach would generate. Your investigators will spend time researching context that an entity-layer system would surface automatically. Budget for higher analyst headcount or accept longer investigation cycles.
Path B: Entity-Layer Surveillance
Choose this path if you're a trade finance platform, a bank with a large import/export client base, or a fintech that has access to detailed supply chain data as part of your core product.
When it works: Your KYC process already collects trade documentation, beneficial ownership structures, and supplier/buyer relationships. You can build customer risk profiles that incorporate trading patterns over months or quarters. Your payment volume per customer is high enough that entity-level patterns become statistically meaningful.
Implementation approach: Build surveillance that tracks:
- Changes in trading partners or commodity types that don't match the customer's declared business model.
- Corporate structures that involve jurisdictions flagged in your National Risk Assessment.
- Politically Exposed Persons in the beneficial ownership chain (Recommendation 12 requires active monitoring of PEPs throughout the customer lifecycle).
- Trading relationships that span multiple jurisdictions in ways consistent with TBML typologies.
Regulatory coverage: This addresses Recommendation 10's customer due diligence requirements and Recommendation 2's call for effective cooperation mechanisms. If your jurisdiction has published an NRA that identifies TBML as a material threat, entity-layer surveillance demonstrates you've tailored your controls to identified risks.
Operational reality: You need access to trade documentation and corporate registry data that most payment processors don't collect. Your detection latency is higher, you're identifying suspicious patterns over weeks or months, not flagging individual transactions in real time. If a customer is actively laundering through rapid transaction sequences, you won't catch it until your next entity review cycle.
Path C: Hybrid Architecture
Choose this path if you're scaling a fintech with growing trade finance exposure, if your regulator has cited TBML as a priority in recent examinations, or if you're seeing alert patterns that suggest your current single-layer approach is missing schemes.
When it works: You have both transaction data and entity context. Your engineering team can build systems that enrich transaction alerts with customer risk scores. Your compliance team has the expertise to interpret multi-signal alerts that combine payment anomalies with entity-level red flags.
Implementation approach: Start with transaction monitoring as your first line of defense. When a payment triggers an alert, automatically pull the customer's entity risk profile:
- Current PEP status and ownership structure.
- Historical trading patterns and typical transaction values.
- Jurisdictional risk based on your NRA or public sector threat assessments.
- Recent changes to business model or trading partners.
Escalate to investigation only when transaction signals align with entity risk factors. This reduces false positives while maintaining real-time detection capability.
Regulatory coverage: This is the most defensible approach if your regulator challenges your TBML controls. You're demonstrating risk-based supervision at the institutional level. You're applying both transaction monitoring and customer due diligence. You're using National Risk Assessment insights to prioritize resources.
Operational reality: You need integration between your transaction monitoring system and your KYC/CDD platform. You need analysts who can interpret multi-dimensional risk signals, not just rule-based alerts. Your technology investment is higher, but your cost per true positive is lower than either single-layer approach.
Summary Matrix
| Factor | Transaction-Layer | Entity-Layer | Hybrid |
|---|---|---|---|
| Best for | Payment processors, early-stage fintechs | Trade finance platforms, banks | Scaling fintechs, high-TBML-risk institutions |
| Data requirements | Payment details only | Trade docs, ownership structures, supplier networks | Both transaction and entity data |
| Detection latency | Real-time | Days to months | Real-time with entity context |
| False positive rate | High | Low | Medium |
| Regulatory coverage | Transaction monitoring, SAR filing | CDD, PEP monitoring, risk assessment | Comprehensive |
| Engineering complexity | Low | Medium | High |
| Analyst skill requirements | General AML knowledge | Trade finance expertise | Multi-signal analysis capability |
The right choice depends on your current capabilities and your risk exposure. More than 200 countries and jurisdictions have committed to implementing the FATF Recommendations, which means your regulator expects you to tailor your approach to the threats your institution actually faces. If your National Risk Assessment identifies TBML as a material threat and you're processing cross-border payments for import/export clients, a transaction-only approach won't satisfy your obligations under Recommendation 10.
Start with the architecture that matches your current data access and operational capacity. Plan the migration path to hybrid as your business scales and your TBML exposure grows. The worst outcome isn't choosing the "wrong" path, it's building detection logic that can't evolve when your risk profile changes.
