FINTRAC 24-Hour Rule Examples: How to Aggregate Cash, EFT and Virtual Currency Transactions

Introduction

A compliance analyst at a payment processor reviews three cash deposits received on the same day at different branch locations. One deposit is $7,000 received at 9:30 am. Another is $5,000 received at 2:15 pm at a different location. The third is $3,200 received at 6:45 pm, this time from a related third party acting on behalf of the original depositor. When reviewed individually, none triggers a standalone reporting obligation. But viewed together, the combined amount of $15,200 suggests a potential reporting event. The challenge is not simply whether the total exceeds $10,000 CAD. The analyst must determine whether these three transactions fall within the same applicable aggregation period, share a recognized aggregation connection under FINTRAC's rules, and belong to the same report type.

The 24-hour rule is frequently misconfigured in transaction-monitoring systems. Many compliance teams treat it as a simple daily total — counting every dollar a customer moves in a calendar day and comparing it to the $10,000 threshold. Others apply a single aggregation logic across all report types, not recognizing that cash transactions, electronic funds transfers, and virtual currency receipts follow distinct aggregation rules. Some systems ignore beneficiaries or third-party relationships, focusing only on the person or entity initiating the transaction. The result is missed reports that should have been filed, duplicate submissions that create confusion, and incomplete records when a single transaction legitimately appears in more than one aggregation report.

This guide uses original practical examples to show how to apply the 24-hour rule correctly. Each scenario demonstrates which transactions must be aggregated, which must remain separate, and when a single transaction requires multiple reports. The guidance applies the current FINTRAC policy as of October 2023 and distinguishes between static 24-hour windows and other reporting timelines.

Quick Answer: How Does FINTRAC's 24-Hour Rule Work?

The 24-hour rule requires reporting entities to treat multiple transactions of the same type as a single reportable transaction when three conditions are met: the combined amount equals or exceeds $10,000 CAD (or its equivalent in foreign or virtual currency), the transactions occur within a consecutive 24-hour period established by your organization, and they share a recognized aggregation connection. That connection depends on the report type and may involve the conductor (the person or entity making the transaction), the beneficiary (the person or entity receiving the funds), or a third party (a person or entity on whose behalf the transaction occurs). Critically, cash deposits, electronic fund transfers, and virtual currency receipts cannot be combined into a single $10,000 calculation — each report type applies its own aggregation rules independently.

The Three Tests Behind Every Aggregation Decision

Every aggregation decision depends on three independent tests, all of which must be satisfied:

Test 1: Same Applicable Transaction Type

The transaction must fall within one of the four report categories that use the 24-hour rule: large cash transactions, large virtual currency transactions, electronic funds transfers, or casino disbursements. A cash deposit cannot be combined with a virtual currency receipt, and an international EFT cannot be mixed with a cash withdrawal. Each type follows its own form and submits under its own regulatory requirement.

Test 2: Within the Correct Report-Specific Period

Your organization establishes a static 24-hour window — for example, 9:00 am Monday to 8:59 am Tuesday. Every transaction must fall within that exact 24-hour window. A transaction at 9:01 am on Tuesday falls in the next window, even if it is only two minutes after a transaction at 8:59 am on Tuesday. The period is consecutive, not rolling, and cannot exceed 24 hours.

Test 3: Same Recognised Aggregation Identity

The aggregation identity depends on the report type. For cash and virtual currency, aggregation may occur based on conductor, beneficiary, or third party. For international EFTs, initiation and final receipt use different identities. Your compliance policies must clearly document which connections trigger aggregation and which do not.

Cash, EFT and Virtual Currency: Rules at a Glance

Cash Scenario One: Several Deposits by the Same Conductor

Scenario

A currency exchange business operates three branch locations across the Greater Toronto Area. The business has established a static 24-hour window from midnight to 11:59 pm. On Thursday, the following cash deposits occur:

Analysis

The business applies Test 1: All three transactions are cash receipts — same transaction type. Test 2: All three occur within the static 24-hour window (midnight to 11:59 pm Thursday). Test 3: All three transactions have Marcus as both the conductor and the beneficiary. Combined, the three deposits total $14,800 CAD, exceeding the $10,000 threshold. The business must submit one Large Cash Transaction Report under the 24-hour rule aggregating these three transactions by conductor (Marcus). If the business's policies and procedures define the beneficiary aggregation separately from the conductor aggregation, a second report is not required here because all three transactions have the same beneficiary (also Marcus). The business may choose to submit a single aggregated report based on conductor or beneficiary — either approach results in the same transaction set.

Cash Scenario Two: A Third Party Connects Otherwise Different Transactions

Scenario

A jewellery store receives cash from two different individuals within the same 24-hour window. Deposit 1: $8,200 cash from Paul for the purchase of a necklace. Deposit 2: $6,500 cash from Sophia for the purchase of earrings. The store's compliance system flags the total as $14,700. However, on deeper review, the store's Know Your Customer file reveals that Sophia informed the store she was acting as an agent for a family trust, and Paul mentioned he was also purchasing on behalf of the same family trust. The trust is the true beneficial interest holder in both cases.

Analysis

Test 1: Both are cash transactions. Test 2: Both occur within the 24-hour window. Test 3: The transactions do NOT share the same conductor (Paul vs. Sophia) and do NOT share the same beneficiary (each purchased different items for their own interests). However, both transactions share the same third party (the family trust on whose behalf each conductor acted). The aggregation rule for cash transactions permits aggregation when transactions are conducted on behalf of the same person or entity. The store must submit one Large Cash Transaction Report aggregating both deposits by the third-party connection (family trust), totalling $14,700. The report identifies the third-party aggregation key and documents which individual conducted each transaction and what each transaction was for. This outcome differs from conductor-based or beneficiary-based aggregation because the two conductors are distinct and the items purchased differ. Third-party aggregation captures the common hidden interest.

Cash Scenario Three: A Shared Beneficiary Produces an Additional Report

Scenario

A money remittance business receives the following cash transactions on the same day from 9:00 am to 10:30 pm: Transaction A: $7,300 from Andrea to deposit into David's account. Transaction B: $6,200 from Andrea to deposit into David's account. Transaction C: $5,400 from Brett to deposit into Naomi's account. Transactions A and B share the same conductor (Andrea) and the same beneficiary (David). Transaction C has a different conductor (Brett) and a different beneficiary (Naomi).

Analysis

Applying the three tests: Test 1 passes for all (cash transactions). Test 2 passes for all (same 24-hour window). Test 3 requires separate analysis by aggregation type. Conductor aggregation: Transactions A and B share conductor Andrea (combined $13,500). Transaction C (Brett) does not match. Report 1 will aggregate by conductor. Beneficiary aggregation: Transactions A and B share beneficiary David (combined $13,500). Transaction C (Naomi) does not match. Report 2 will aggregate by beneficiary. Transactions A and B appear in both Report 1 and Report 2, but this is not duplication — it is correct reporting. The reason is that Report 1 also would include any other transactions from Andrea to any beneficiary in the window, and Report 2 would include any other transactions from any conductor to David in the window. In this case, the only transactions in each window occur between the same parties, but the aggregation basis is independently assessed. Both reports are submitted; each contains the transactions satisfying that report's aggregation criteria. Transaction C does not meet the $10,000 threshold under any single aggregation key, so it requires no report unless it individually exceeds $10,000 (which it does not).

A Cash Transaction Above $10,000 Followed by Smaller Amounts

When a single transaction independently reaches or exceeds $10,000, the transaction must be reported. The regulatory change effective October 21, 2023 clarified that if that transaction is also part of an aggregation group in the same 24-hour window, it does not need to be reported twice. Instead, it appears in the aggregation report. For example: Transaction 1 at 10:00 am: $12,500 cash from Quinn for personal investment. Transaction 2 at 2:30 pm: $4,200 cash from Quinn for the same investment purpose. Both are within the static 24-hour window and share the same conductor (Quinn) and (implicitly) the same beneficiary. Under prior guidance (before June 2021), Transaction 1 would have been reported separately because it individually exceeded $10,000, while Transaction 2 would not have triggered a report (being below threshold). The 2021 regulatory change means Transaction 1 and Transaction 2 are now aggregated together in a single report totalling $16,700. Transaction 1 is not reported twice; it appears once within the aggregation report. This change simplifies reporting and prevents misleading duplication.

International EFT Scenario: Several Requests by the Same Requester

Scenario

A bank initiates the following international electronic funds transfers on the same day within its static 24-hour window (6:00 am to 5:59 am next day):

Analysis

All three transfers are international EFTs initiated within the static 24-hour window by the same requester (Olivia). The destinations differ (Mexico, Spain, Singapore), and the beneficiaries are distinct entities (Garcia Ltd., Torres SA, Olivia Pte.). The payment channels also differ: two use SWIFT, one uses a non-SWIFT method. Crucially, SWIFT and non-SWIFT transfers are treated identically for aggregation purposes under current guidance. Combined, the three transfers total $11,200 CAD. For EFTR purposes, the relevant aggregation key for initiated transfers is the requester. All three transfers share requester Olivia. The current guidance does not require that beneficiaries be identical for aggregation — only that the transfer type (initiation), the requester, and the window align. The bank must submit one Electronic Funds Transfer Report aggregating all three initiation transactions by requester, totalling $11,200. Each transfer appears in the report with its own destination, beneficiary, and method. The fact that one transfer is non-SWIFT does not prevent aggregation; the channel is not an aggregation barrier.

International EFT Scenario: The Same Beneficiary Receives Transfers From Different Requesters

Scenario

A bank finally receives (rather than initiates) the following international electronic funds transfers within the same static 24-hour window: Transfer 1: $6,000 from a Swiss bank on behalf of Sophia (requester). Transfer 2: $5,200 from a German bank on behalf of Xavier (requester). Transfer 3: $3,100 from a UK bank on behalf of Zara (requester). All three transfers are intended for deposit into the account of Catalyst Investments Ltd.

Analysis

Test 1: All three are international EFTs. Test 2: All three occur within the static 24-hour window. Test 3: For final receipt of EFTs, the relevant aggregation keys are different from initiation. The current guidance specifies that for final receipt, aggregation occurs based on: the requester (the person whose request led to the transfer), OR the beneficiary (the entity receiving the funds). The three requesters differ (Sophia, Xavier, Zara), so there is no requester-based aggregation. However, all three transfers are for the same beneficiary (Catalyst Investments Ltd.). Therefore, aggregation is triggered by the shared beneficiary. The combined total is $14,300 CAD. The bank must submit one Electronic Funds Transfer Report for the final receipt of these three transfers, aggregated by beneficiary (Catalyst Investments Ltd.), totalling $14,300. Each transfer is listed with its own source bank, requester, and amount. The different requesters do not prevent aggregation for final receipt purposes; the beneficiary is the aggregation key.

EFT Transactions That Must Remain Separate

Initiated international EFTs and finally received international EFTs are assessed under separate aggregation rules and never combined. A bank that initiates a $7,000 transfer and later finally receives a $6,000 transfer to the same beneficiary on the same day cannot aggregate them into a single $13,000 report. Instead, the initiated transfer is evaluated against other initiated transfers, and the received transfer is evaluated against other received transfers. If neither grouping reaches $10,000, no EFTR reports are required.

Domestic electronic fund transfers within Canada are not subject to EFTR reporting, regardless of amount. A $15,000 domestic transfer between two Canadian banks does not trigger the 24-hour rule or an EFTR obligation, even if other domestic transfers push the total above $10,000.

Transfers that fall outside the static 24-hour window are tested independently in their own window. A $6,000 transfer at 11:50 pm on Monday and a $5,500 transfer at 12:15 am on Tuesday (both within a calendar day) fall in separate 24-hour windows if the organization's window is, for example, midnight to 11:59 pm. They do not aggregate.

Transfers for which no common requester or beneficiary is known cannot be aggregated. A bank receives an $8,000 transfer from an unknown requester and another $7,000 transfer from a different unknown requester for different beneficiaries on the same day. Without identifying either the requester or confirming a shared beneficiary, no aggregation occurs, and no EFTR is required.

Virtual Currency Scenario: Multiple Receipts Across Wallet Addresses

Scenario

A Canadian cryptocurrency exchange receives the following virtual currency deposits within the same static 24-hour window (9:00 am to 8:59 am next day): Receipt 1 at 10:30 am: 0.3 Bitcoin deposited to wallet address starting with 1A2b (equivalent to $6,800 CAD at the exchange rate used by the platform that hour). Receipt 2 at 1:15 pm: 5 Ethereum deposited to wallet address starting with 3C4d (equivalent to $7,200 CAD). Receipt 3 at 4:45 pm: 15,000 USDC (USD Coin, a stablecoin) deposited to wallet address starting with 2E5f (equivalent to $15,050 CAD, accounting for the stablecoin's 1:1 peg to USD and conversion at the relevant exchange rate). All three deposits are credited to the account of Riley, a registered user.

Analysis

Test 1: All three are virtual currency receipts — same transaction type. Test 2: All three occur within the static 24-hour window. Test 3: The question is whether the three receipts share an aggregation identity. The wallet addresses differ (1A2b, 3C4d, 2E5f), but they all belong to the same customer, Riley. In fact, they all funnel into Riley's account. The aggregation rule asks whether transactions share a conductor, beneficiary, or third-party connection. Here, Riley is the beneficiary of all three deposits. The combined CAD-equivalent amount is $29,050, well above the $10,000 threshold. The exchange must submit one Large Virtual Currency Transaction Report under the 24-hour rule aggregating all three receipts by beneficiary (Riley), totalling $29,050 CAD. The report records each virtual asset type, amount in that asset, wallet address from which it was received, and the CAD-equivalent value at the time of receipt. Different wallet addresses do not prevent aggregation; they are documented as part of the transaction details. The exchange retains evidence of the exchange rates used and when each conversion took place.

Virtual Currency Exceptions and Special Beneficiaries

The current FINTRAC guidance provides exceptions for aggregated virtual currency receipts when the beneficiary falls into specific categories. If an exchange receives 2 or more virtual currency deposits totalling $10,000 or more within a 24-hour window, but the beneficiary is a public body (a government entity, municipality, or public agency), the exchange does not have to submit an LVCTR for the aggregated receipts. Similarly, if the beneficiary is a very large corporation or trust with minimum net assets of $75 million on its last audited balance sheet and whose shares or units trade on a Canadian stock exchange (or a prescribed foreign exchange), and the entity operates in a Financial Action Task Force member country, no LVCTR is required for the aggregated receipts. The same exception applies if the beneficiary is an administrator of a federally or provincially regulated pension fund.

However, if ANY INDIVIDUAL virtual currency deposit independently reaches $10,000 or more, the exception does not apply. In that case, the exchange must file a separate LVCTR for each individually reportable amount, even if the beneficiary otherwise qualifies for an exception. For example, if an exchange receives a $12,000 deposit and a $3,000 deposit for the same public body in the same 24-hour window, the $12,000 deposit must be reported independently; the beneficiary's public body status does not shelter it.

Different Branches, Systems and Time Zones

A large financial institution operates branches in British Columbia (Pacific Standard Time), Alberta (Mountain Standard Time), Ontario (Eastern Standard Time), and Nova Scotia (Atlantic Standard Time). The organization must select a single time zone for its aggregation window or define how multi-location transactions are normalized. If the organization establishes a 24-hour window of 9:00 am to 8:59 am Eastern Standard Time, then a transaction occurring at 6:30 am PST in Vancouver must be converted to EST (9:30 am EST) before determining whether it falls within the window. The institution's policies must clearly document this conversion rule and apply it consistently.

In practice, most organizations choose one reference time zone for all aggregation calculations or require that transaction times be recorded in Coordinated Universal Time (UTC) at the moment of receipt, then converted to the reference time zone for aggregation analysis. Some organizations operate separate 24-hour windows for different channels — for example, a 24-hour window for in-branch cash transactions (9 am to 8:59 am local time at each branch) and a different window for online transactions (midnight to 11:59 pm UTC). The key requirement is that policies document the chosen approach and systems implement it consistently.

Transaction-monitoring systems should flag transactions with timestamps, receive times, and UTC offset so that conversion can be verified during audit or examination. When transactions from different branches or channels arrive in the system at different times due to processing delays, the system must still assess them against the aggregation window based on when they actually occurred (transaction time), not when they were recorded or processed.

What Your Monitoring System Must Capture

An effective transaction-monitoring system designed to handle the 24-hour rule must capture and retain the following fields or data elements to support reporting, audit, and examination: