Training › Developer Path
Developer 2 Required · 2 Optional ~2 hours total

Developer Learning Path

Developers building financial systems must understand the compliance requirements that govern the systems they build. This path focuses on what BSA and OFAC mean for system design — data retention, screening integration, CTR triggers, and SAR-safe logging.

// Why developers need compliance training
const reasons = [
  "Application logs may capture SAR-related data — understand retention requirements",
  "OFAC screening must be integrated at account creation and before each transaction",
  "CTR threshold logic must aggregate across accounts and business days",
  "Beneficial ownership data must be collected and stored per FinCEN CDD requirements",
  "Tipping off via email/notification bugs is a legal liability"
];
System Design Checklist
  • OFAC screening at account creation
  • OFAC screening before each outbound wire
  • CTR aggregation by customer, same-day
  • 5-year record retention for all transactions
  • Beneficial ownership fields in customer schema
  • SAR BSA ID stored in incident management system
  • No SAR status exposed in customer-facing UI or emails
1
REQUIRED
Module 1: Bank Secrecy Act (BSA)
Developer focus areas:
  • Lesson 1.2 — CDD: what fields you must collect and store at account opening
  • Lesson 1.3 — CTR aggregation logic: same business-day, same customer scope
  • Lesson 1.4 — Record retention: 5-year minimum for all BSA-covered records
Start Module →
2
REQUIRED
Module 2: OFAC Screening
Developer focus areas:
  • Lesson 2.1 — 50% rule: implications for how you query and store ownership data
  • Lesson 2.2 — When to call the screening API: at onboarding, before wire sends, and on SDN list updates
  • Lesson 2.3 — System behavior for blocked transactions: hold funds, do not return error to customer
Start Module →
3
OPTIONAL
Module 3: AML Transaction Monitoring
Relevant if you're building transaction monitoring features or TMS integrations. Focus on Lesson 3.3 — TMS rules engine logic (velocity checks, peer group deviation, geographic risk) and what data fields your system must capture for TMS to function correctly.
Start Module →
4
OPTIONAL
Module 4: SAR Filing Procedures
Relevant if your system surfaces case management or SAR workflow features. The tipping-off prohibition (Lesson 4.2) has critical UI/UX implications: no customer-facing system should expose SAR status, and automated notifications must never reference compliance holds.
Start Module →

Compliance System Design Reference

Data Retention Requirements
  • Account records: 5 years after account closure
  • CTRs: 5 years from filing date
  • SARs: 5 years from filing date (BSA ID retained)
  • OFAC screening records: 5 years
  • CDD/EDD documents: 5 years after end of relationship
Tipping-Off Risks in System Design
  • Never expose SAR status in customer dashboard
  • Transaction hold emails must not mention compliance review
  • Account restriction notifications must use neutral language
  • Internal compliance flags must be access-controlled
  • Audit logs containing SAR data require restricted access