Structuring is one of the most straightforward BSA violations conceptually — deliberately breaking up transactions to stay below the $10,000 Currency Transaction Report threshold — and one of the most technically demanding to detect reliably at scale. The gap between understanding what structuring is and building a detection program that holds up under examination is where many growing digital banks discover their monitoring system has a significant blind spot.
The CTR Obligation: Basics That Get Missed
Under 31 CFR 1010.311, financial institutions must file a Currency Transaction Report for cash transactions exceeding $10,000 on a single business day. The key phrase is cash transactions — CTRs apply to currency, not electronic transfers. For most consumer-focused neobanks operating in the digital payments space, cash transactions are relatively uncommon. But for institutions with card-linked cash deposit functionality, retail reload networks, or business account customers, CTR obligations are live and consequential.
The aggregation requirement is where institutions most commonly fail. CTRs are required not only for individual transactions over $10,000 but for multiple transactions by the same person that aggregate to over $10,000 in currency in a single business day. An institution that only looks for single transactions at or above the threshold and misses the aggregation requirement is filing incomplete CTRs — or not filing CTRs it was required to file.
Technically, the aggregation clock runs per business day, per customer, across all branches and access points of the institution. For a digital bank with a single-channel model, this is simpler than for a traditional bank with 200 branches. But the aggregation logic still needs to be explicitly built — it is not automatic.
Structuring: The Detection Problem
Structuring under 31 USC 5324 is the willful act of breaking up transactions to evade the CTR filing requirement. The criminal element is intent — but from a BSA monitoring standpoint, the compliance obligation is to flag patterns consistent with structuring regardless of whether intent is established. The SAR is the mechanism for reporting; establishing intent is law enforcement's job.
What makes structuring detection technically challenging in high-volume digital banking is the aggregation logic required. A series of cash deposits — $2,400 on Monday, $3,200 on Wednesday, $4,100 on Friday — across three different days, each well below $10,000, constitutes a potential structuring pattern. Detecting it requires your monitoring system to aggregate transaction activity across a rolling lookback window, attribute multiple transactions to the same account, and compare the aggregate against the $10,000 threshold.
Most off-the-shelf rule engines that come pre-configured for digital banks do this within a single business day. They don't necessarily do it across multiple days, which is where the smurfing pattern lives. Smurfing — distributing structuring activity across multiple accounts, multiple time periods, and multiple access points — is specifically designed to defeat single-day aggregation detection.
Building Multi-Day Aggregation Logic
A structuring detection program that operates only within a single calendar day is inadequate for current typologies. The multi-day aggregation rules that regulators expect to see in place operate something like this:
- Same-day aggregation: All cash transactions by the same customer on the same business day aggregate toward the CTR threshold. This is the baseline requirement.
- Rolling 3-day window: Transactions in the $7,000–$9,900 range should also trigger a multi-day lookback. If a customer makes $9,800 in cash deposits on Monday and $9,700 on Wednesday, neither triggers a same-day CTR, but the pattern warrants a structuring alert.
- Rolling 30-day window: For accounts with consistent below-threshold deposit activity, a monthly aggregation scan can identify customers whose total cash activity far exceeds $10,000 while each individual transaction stays below the report threshold.
The 30-day window is the one most often missing from smaller digital bank monitoring programs. It requires storing and querying transaction history across a month-long lookback, which imposes computational requirements that simple threshold rules don't have. Building it in from the start is easier than retrofitting it when an examiner points to the gap.
Micro-Transaction Structuring in P2P and Digital Payment Rails
Traditional structuring detection was designed around cash deposit windows at teller counters. Digital banking creates a new variant: micro-transaction structuring through peer-to-peer rails and card-linked deposit networks. Here the transaction amounts are smaller, the frequency is higher, and the aggregation logic is harder because the transactions look superficially like normal digital payment behavior.
A pattern we've analyzed in neobank transaction data involves accounts receiving dozens of small P2P transfers in the $200–$800 range from multiple senders within a 48-hour window, accumulating aggregate inflows in the $8,000–$12,000 range, followed by a rapid outbound transfer. Individual transactions are trivially small. The aggregate behavior is characteristic of a mule account receiving layered inflows.
This is where the distinction between CTR structuring (cash-specific) and suspicious activity monitoring (broader behavioral patterns) becomes operationally important. The individual P2P transactions may not trigger CTR aggregation obligations if they're electronic transfers rather than currency. But the behavioral pattern is a SAR trigger — suspicious activity that warrants investigation regardless of the cash/non-cash distinction.
What Examiners Look For in CTR Programs
Examiners reviewing a digital bank's CTR program will typically pull a sample of accounts with cash transaction histories and test whether appropriate CTRs were filed. The specific tests include: single transaction over $10,000 with no CTR filed; same-day multi-transaction aggregate over $10,000 with no CTR; accounts with obvious structuring patterns in the transaction history and no SAR filing or adequate case disposition.
We're not saying every missed CTR generates enforcement action. Isolated filing errors with documented explanations and remediation plans are typically addressed as MRAs, not consent orders. What examiners are looking for is whether the program design is structurally capable of detecting the obligations it's supposed to detect. A program that systematically misses same-day aggregation has a structural deficiency, not an isolated error. That distinction drives the severity of the examination response.
CTR structuring detection is not just about the $10,000 threshold. It's about the aggregation logic that makes the threshold meaningful. Build the multi-day window in; don't wait for an exam to discover it was missing.
