CTMA Exam Overview and Format
About the CTMA exam
The Certified Transaction Monitoring Associate (CTMA) is an associate-level ACAMS certification for people developing practical skills in transaction monitoring, alert investigation, documentation, escalation, and reporting outcomes. It is relevant to transaction monitoring analysts, AML operations staff, and professionals who support financial-crime investigations.
ACAMS describes the exam as 60 questions in 90 minutes. The exam includes unscored pilot items, and the stated passing threshold applies to scored items: 74 percent. Check current exam details with ACAMS before booking, because delivery arrangements can change.
How to use this guide
This independently written guide organizes the subject into four learning areas: monitoring fundamentals, investigation, suspicious activity indicators, and escalation and reporting. It emphasizes explaining why an alert fired, weighing evidence in context, and choosing a defensible next step. The domain priorities below are editorial study guidance, not official exam weights.
This guide is written in English. A study guide’s language does not establish which languages are available for the official exam. Confirm current language availability and booking details directly with ACAMS CTMA certification information.
CTMA study map
| Learning area | Main topics | Study priority |
|---|---|---|
| Transaction monitoring fundamentals | Monitoring purpose and approaches; alert scenarios and thresholds; peer groups; customer profiles; alert causes; data quality. | Be able to trace an alert to its scenario, inputs, and customer context. |
| Alert investigation process | Triage; evidence gathering; customer and account context; linked activity; investigation notes; closure rationale; quality review. | Practice a clear, evidence-led investigation from alert to disposition. |
| Suspicious activity identification | Structuring indicators; layering and rapid movement; trade-related concerns; fraud proceeds; cyber-related activity; mule networks; anomalies. | Connect indicators to possible typologies without treating them as proof. |
| Escalation and reporting | Internal escalation; suspicion assessment; reporting roles; tipping-off risk; handoffs; quality assurance; management information; control feedback. | Distinguish closing, continued monitoring, and escalation under policy and applicable law. |
60 concepts to know and apply 1–10
1. Why transaction monitoring exists
Transaction monitoring fundamentals
Transaction monitoring helps an institution identify activity that may be inconsistent with known customer information or relevant risk patterns. It supports review and decision-making; it does not establish wrongdoing on its own. Monitoring is most useful when alert results lead to proportionate investigation, reliable documentation, and feedback that improves the institution’s controls.
Example: A small business’s account begins receiving frequent transfers from unrelated parties. Monitoring highlights the change so an analyst can compare it with the business profile and investigate the context.
Common misconception: An alert is not a finding of criminality. It is a prompt for review, and the investigator must assess the available facts before deciding whether any further action is justified.
2. Risk-based monitoring
Transaction monitoring fundamentals
A risk-based approach directs attention according to relevant exposure, customer context, products, channels, and observed activity. It aims to apply scrutiny proportionately rather than treating every account or transaction identically. Risk ratings can inform monitoring, but they should not replace transaction-level review or prevent new information from changing the assessment.
Example: An institution may apply different review scenarios to a cash-intensive business and a salaried individual, while still investigating an unusual pattern for either customer.
Common misconception: Risk-based does not mean high-risk customers are automatically suspicious or low-risk customers are exempt from scrutiny. New behavior can warrant review regardless of an existing label.
3. Rule-based monitoring
Transaction monitoring fundamentals
Rule-based monitoring applies defined logic to data, such as transaction type, time period, amount pattern, or customer attributes. A rule can be clear and explainable, but its performance depends on sound design and reliable inputs. Rules identify activity matching specified conditions; they do not determine whether that activity has a legitimate explanation.
Example: A rule flags multiple incoming transfers followed by outward payments within a short period. The analyst checks whether the sequence matches the customer’s stated business activity.
Common misconception: A rule firing does not mean the rule has correctly identified suspicious activity. It means the observed data met the rule’s configured conditions and still needs review.
4. Monitoring scenarios
Transaction monitoring fundamentals
A scenario is a defined monitoring pattern intended to identify activity associated with a risk or typology. Its logic may combine transactions, customer attributes, time windows, and relationships. Knowing the scenario helps an investigator understand what was detected, what it did not test, and which evidence would help assess the alert.
Example: An alert references a rapid-inflow-and-outflow scenario. The analyst identifies the transactions that formed the sequence, then checks counterparties, account purpose, and the timing of each movement.
Common misconception: Do not infer the full story from a scenario name. Read the alert details and underlying logic; similar labels can represent different data, conditions, or time periods.
5. Thresholds and alert sensitivity
Transaction monitoring fundamentals
A threshold is a configured condition that helps determine when activity triggers review. A lower or broader threshold may capture more activity but also produce more alerts; a narrower one may reduce volume while missing relevant patterns. Thresholds are monitoring settings, not automatic legal conclusions about suspiciousness or reporting obligations.
Example: A cash-activity scenario begins generating many alerts after a threshold is changed. The monitoring team reviews the affected cases and assesses whether the change improved detection or mainly increased noise.
Common misconception: A transaction just below a threshold is not automatically suspicious, and one above it is not automatically reportable. The threshold explains alert generation, not the final case decision.
6. Aggregation and pattern detection
Transaction monitoring fundamentals
Aggregation brings related transactions together across a defined period or relationship so that a pattern is visible beyond individual payments. This can reveal repeated activity, movement across accounts, or behavior that appears ordinary one transaction at a time. Reviewers should understand what was aggregated and whether the links and time window are reliable.
Example: Several modest cash deposits at different branches appear routine individually. An aggregate view reveals their concentration over a short period, prompting comparison with the customer’s normal business cycle.
Common misconception: Aggregation does not prove that transactions share a purpose or owner. Confirm the account links, dates, and relevant context before treating a combined pattern as meaningful.
7. Peer groups
Transaction monitoring fundamentals
Peer groups compare a customer’s activity with that of broadly similar customers, such as businesses with comparable characteristics. They can help identify outliers that a simple fixed rule might miss. Their value depends on appropriate grouping variables, sufficient data, and awareness that a group average does not define what is legitimate for every member.
Example: A retailer’s transfer activity is much higher than that of comparable local retailers. The analyst checks the retailer’s own history, business model, and recent changes before interpreting the difference.
Common misconception: Being an outlier is a reason to examine context, not a conclusion of suspicion. A peer group can be poorly matched or fail to reflect a customer’s unique but legitimate circumstances.
8. Customer profiles as monitoring inputs
Transaction monitoring fundamentals
Customer profiles supply information used to interpret expected activity, including occupation or business type, account purpose, products, and relevant risk details. A profile is a starting point, not an unchanging truth. Monitoring and investigation depend on recognizing when information may be incomplete, stale, inconsistent, or no longer representative.
Example: An alert describes a customer as a salaried individual, but the file shows the customer recently opened a business account. The analyst checks which profile data the scenario actually used.
Common misconception: Do not treat a profile label as proof of current behavior or risk. Verify relevant information and identify whether a profile defect contributed to the alert.
9. Expected activity and customer baseline
Transaction monitoring fundamentals
A baseline describes activity reasonably expected for a particular customer based on available information and observed history. Comparing current behavior with that baseline can expose meaningful changes. The comparison should account for seasonality, business growth, product use, and known life or operational events rather than assuming the past will always repeat.
Example: A seasonal retailer’s deposits rise during its normal busy period. The analyst compares the increase with prior seasonal patterns and account context before deciding whether it is unusual.
Common misconception: A change from historical behavior is not automatically suspicious, and familiar activity is not automatically safe. Explain what changed and assess whether the available context accounts for it.
10. Alert, investigation, and case
Transaction monitoring fundamentals
An alert is a signal generated for review; an investigation is the work of testing that signal against evidence and context; a case is a structured record used when activity or related alerts require further handling. Institutions may use these terms differently, so analysts should follow local workflow definitions and avoid treating an alert as a completed conclusion.
Example: A single scenario creates an alert. Review links it to earlier activity, so the analyst follows the institution’s process for consolidating related alerts into a case.
Common misconception: Closing an alert does not necessarily resolve every related concern, and opening a case does not prove misconduct. Use the institution’s workflow and record the reason for each transition.
60 concepts to know and apply 11–20
11. Tracing an alert to its cause
Transaction monitoring fundamentals
To explain why an alert fired, trace it back to the scenario, conditions, customer attributes, transaction records, and relevant time period. This distinguishes a genuine activity pattern from an incorrect input or configuration problem. Knowing the trigger also helps the investigator select useful evidence rather than reviewing unrelated material.
Example: An alert cites a high-volume transfer pattern. The analyst checks the included transactions, the scenario period, and whether the account relationship and customer category were mapped correctly.
Common misconception: Repeating the alert label is not an explanation. A defensible account identifies the actual transactions and conditions that caused the system to generate the alert.
12. Data quality
Transaction monitoring fundamentals
Data quality concerns whether monitoring inputs are accurate, complete, timely, and consistently represented. Errors such as missing transactions, incorrect customer types, or stale profile details can distort both detection and investigation. Analysts who find a material data issue should document its effect and use the appropriate channel to request correction or review.
Example: A customer’s profile still lists a former occupation, leading a scenario to compare business receipts with an unsuitable expected-activity category. The analyst records the defect and routes it for correction.
Common misconception: Do not dismiss an alert as noise merely because one data field appears wrong. Establish how the defect affected the alert and whether other reliable evidence still warrants review.
13. Data lineage and provenance
Transaction monitoring fundamentals
Data lineage describes where information originated and how it moved or changed before appearing in a monitoring or case system. Provenance helps reviewers assess whether a field or transaction record can be relied upon and whether discrepancies arose in collection, transfer, or transformation. It also makes defects easier to route to the right control owner.
Example: A case display shows a transaction date that differs from the source statement. The analyst records both sources and asks the relevant operations team to clarify the discrepancy.
Common misconception: A value shown in a system is not automatically accurate just because it is system-generated. When a material conflict appears, identify the source and seek appropriate verification.
14. False positives and meaningful alerts
Transaction monitoring fundamentals
A false positive is an alert that review finds does not warrant further concern under the institution’s criteria; it can still reveal a data or design issue. Conversely, an alert that merits investigation is not necessarily confirmed suspicious activity. The useful distinction is between system detection and the evidence-supported outcome of review.
Example: A recurring payment triggers a scenario, but invoices and the customer’s established business relationship explain the pattern. The reviewer closes it with a clear rationale and notes any recurring system issue.
Common misconception: Do not equate false positive with worthless review, or alert with confirmed risk. A sound disposition explains what the evidence supports and whether a control issue needs attention.
15. Monitoring feedback and tuning
Transaction monitoring fundamentals
Feedback from investigations can help control owners assess whether scenarios, thresholds, data, or profiles are working as intended. Tuning should be evidence-led and governed: reducing alert volume alone is not a sufficient objective if relevant activity might be missed. Frontline analysts should report recurring issues rather than independently changing monitoring logic outside their authority.
Example: Reviewers repeatedly find that a scenario flags a common, documented payment pattern. They submit examples and closure reasons to the monitoring team for controlled assessment.
Common misconception: Do not assume analysts should change a threshold whenever alerts seem noisy. Tuning requires appropriate ownership, testing, documentation, and consideration of both missed detection and alert quality.
16. Triage and prioritization
Alert investigation process
Triage organizes alerts for review using applicable risk indicators, urgency, case links, and institutional procedures. It helps direct attention without replacing investigation. A triage decision should be consistent with the information available at that point, and significant new facts may justify changing priority or routing.
Example: An alert involving rapid movement and a previously reviewed related account is prioritized for timely review under the institution’s queue rules.
Common misconception: Queue priority is not a final risk determination. A lower-priority alert still needs review within applicable procedures, and a high-priority alert still needs evidence-based analysis.
17. Setting the investigation scope
Alert investigation process
A clear investigation scope identifies the activity that triggered review, the period and accounts in view, and the questions that need answering. It keeps work focused while allowing expansion when evidence reveals relevant links or earlier activity. Scope should be broad enough to understand the pattern but proportionate to the alert and available authority.
Example: A transfer alert covers one month. The reviewer checks that period first, then expands to earlier transactions after finding the same counterparty in a prior alert.
Common misconception: Do not either stop at the exact alert boundary despite relevant links or search indefinitely without a purpose. Expand the review when a documented investigative question warrants it.
18. Building a transaction timeline
Alert investigation process
A transaction timeline arranges relevant events in chronological order, including incoming funds, transfers, withdrawals, account changes, and known customer events. It can reveal sequencing and delays that are hard to see in a transaction list. Clear timelines also help another reviewer understand how the analyst reached a conclusion.
Example: An account receives a large transfer, sends portions onward the next day, and then becomes inactive. The timeline makes the sequence and timing clear for further assessment.
Common misconception: A timeline is more than a list of dates and amounts. Explain why the order, interval, or relationship between events matters to the investigation.
19. Customer and business context
Alert investigation process
Customer context helps assess whether observed activity is plausible for the stated account purpose, occupation, business model, and known circumstances. Context should be based on available reliable information and should not be invented to explain an anomaly. Where information is missing or contradictory, record that limitation rather than filling the gap with an assumption.
Example: A wholesaler receives payments from several retailers. The analyst compares the counterparties and payment pattern with the documented business model and the account’s stated purpose.
Common misconception: A plausible story is not the same as verified context. Do not treat an assumed business explanation as established unless supporting information is available.
20. Comparing activity with the customer’s history
Alert investigation process
Historical comparison tests whether current activity differs from the customer’s own prior behavior, which can be more informative than comparison with a broad peer group. Reviewers should consider the length and reliability of the history, normal variation, and relevant changes in the customer’s circumstances before interpreting a deviation.
Example: A long-standing account begins making frequent international payments. The analyst compares the change with prior activity and checks whether the customer’s business or stated needs have changed.
Common misconception: A short or unrepresentative history may not establish a reliable baseline. Do not treat every departure as suspicious or every repeated pattern as acceptable without context.
60 concepts to know and apply 21–30
21. Counterparty review
Alert investigation process
Counterparty review examines who sent or received funds, how the parties relate to the customer, and whether the relationship makes sense in context. The review may consider names, account references, transaction descriptions, and available institutional records. A counterparty’s unfamiliarity is a lead for inquiry, not proof of illicit activity.
Example: A personal account makes repeated payments to newly encountered recipients. The analyst checks available payment details and customer context to understand whether the recipients have a plausible relationship to the account holder.
Common misconception: Do not treat an unfamiliar recipient as inherently suspicious or assume that a familiar name eliminates concern. Assess the transaction purpose and evidence for the relationship.
22. Linked-account analysis
Alert investigation process
Linked-account analysis considers whether related accounts change the meaning of an alert, for example through common ownership, access, contact details, or transaction flows. The strength of each link matters: a shared feature may have innocent explanations. Document the basis for treating accounts as connected and stay within permitted access and investigative procedures.
Example: Several accounts transfer funds among themselves and share an authorized signatory. The analyst records the verified connection and reviews whether the movements have a documented business purpose.
Common misconception: A shared address, device, or name alone may not establish common control or coordination. Describe the link accurately and avoid claiming more than the records support.
23. Source and destination of funds
Alert investigation process
Tracing source and destination helps an analyst understand where funds appear to originate and where they move afterward. It can identify gaps, intermediaries, or a mismatch with the customer’s stated activity. A transaction record may show an immediate sender or recipient without revealing the ultimate origin, beneficial party, or economic purpose.
Example: Funds arrive from a payment service and are quickly sent to several external accounts. The analyst documents the visible flow and identifies what the available records do and do not establish.
Common misconception: Do not describe an immediate counterparty as the ultimate source or beneficiary without evidence. Distinguish observed transaction routes from conclusions about who ultimately controls the funds.
24. Corroborating information
Alert investigation process
Corroboration uses independent or complementary information to test an explanation or observation. Depending on authority and availability, it may include transaction records, account files, internal case history, and reliable customer information. Corroboration strengthens a narrative when sources agree; discrepancies should be recorded rather than concealed or casually resolved.
Example: A customer description says a transfer paid an invoice. The analyst compares the payment timing and account records with available documentation before relying on that explanation.
Common misconception: Repeating one unverified claim in multiple notes does not create independent support. Identify the original source and assess whether another reliable record confirms it.
25. Testing alternative explanations
Alert investigation process
A balanced investigation tests both risk-related interpretations and plausible legitimate explanations against available evidence. This does not mean searching for a reason to dismiss the alert; it means assessing what the facts support and where uncertainty remains. A well-reasoned outcome acknowledges material evidence on both sides.
Example: Several deposits appear unusual, but the customer’s business has a documented seasonal peak. The analyst checks whether timing and amounts fit that pattern and notes any unexplained differences.
Common misconception: Considering an innocent explanation is not the same as accepting it without support. Likewise, a risk hypothesis should not be favored merely because it sounds plausible.
26. Proportionate evidence gathering
Alert investigation process
Evidence gathering should answer the investigation’s questions while respecting applicable procedures, access limits, and the analyst’s role. Review the records most likely to clarify the activity, and broaden the inquiry when findings justify it. Proportionate work is neither a superficial glance nor an unsupported, unlimited search.
Example: A reviewer begins with the alert transactions and account history, then checks related case records after identifying a repeated counterparty.
Common misconception: More data is not automatically better. Collecting unrelated information can obscure the key issue, while stopping before resolving an obvious evidential gap can leave the decision unsupported.
27. Evidence versus typology intelligence
Alert investigation process
Evidence in a case consists of information relevant to the customer and activity under review, such as transaction records or account documentation. Typology reports and risk intelligence help explain why a pattern may matter, but they do not establish what happened in a specific account. Use intelligence to guide questions, then ground conclusions in case evidence.
Example: A public typology describes rapid transfers as a possible layering method. The analyst uses it to examine the customer’s actual flow of funds rather than treating the typology as proof.
Common misconception: A pattern’s resemblance to a published typology does not prove the customer engaged in that conduct. State the observed facts separately from the risk interpretation.
28. Writing a clear investigation narrative
Alert investigation process
A useful narrative lets another reviewer follow the alert, the records examined, relevant context, analysis, and outcome. It separates observation from interpretation and identifies important limitations. Clear writing reduces ambiguity in handoffs and makes quality review more reliable, even when the case remains unresolved or requires escalation.
Example: The analyst summarizes the alert trigger, dates and flows reviewed, customer context, unresolved questions, and the reason for recommending continued monitoring.
Common misconception: A long note is not necessarily a clear note. Avoid unexplained acronyms, copied system text, and conclusions that do not follow from the evidence described.
29. Defensible closure rationale
Alert investigation process
A closure rationale explains why the reviewed activity does or does not require further action under the applicable process. It should refer to material evidence, customer context, and any limits that affected the review. A defensible rationale does not need to claim certainty; it needs to show how the decision followed from the available information.
Example: The reviewer closes a recurring-payment alert after confirming consistent counterparties and an established account purpose, while noting that the observed pattern matched the documented arrangement.
Common misconception: Labels such as “normal activity” or “no concern” do not explain a decision. Link the outcome to specific findings so a later reviewer can assess the reasoning.
30. Quality assurance in investigations
Alert investigation process
Quality assurance checks whether an investigation followed procedure, considered relevant evidence, supported its conclusions, and documented a clear rationale. It can identify individual coaching needs and systemic problems in data, workflow, or scenario design. Quality review is a control, not a substitute for the analyst’s own careful work.
Example: A reviewer finds that a closure note omits linked-account activity. The case is returned for clarification under the institution’s quality process.
Common misconception: A quality check is not satisfied merely because required fields are filled. Assess the substance of the analysis and whether the conclusion is supported.
60 concepts to know and apply 31–40
31. Red flags are indicators, not proof
Suspicious activity identification
A red flag is a feature that may warrant further inquiry because it can be associated with financial crime or other relevant risk. Its significance depends on context, corroborating information, and competing explanations. Several indicators may strengthen a concern, but no indicator should be converted automatically into a finding of criminality.
Example: An account receives funds from an unfamiliar party and sends them onward quickly. The analyst examines the customer’s role, counterparties, and reason for the sequence before recommending a next step.
Common misconception: Do not label a customer criminal because one indicator appears. Red flags guide investigation; conclusions and escalation decisions require an evidence-based assessment.
32. Structuring indicators
Suspicious activity identification
Structuring generally describes transactions arranged or divided in a way that may be intended to avoid scrutiny or a reporting requirement. Repeated amounts, timing, locations, or channels can be indicators, but similar patterns can have legitimate causes. Assess the pattern, the customer’s activity, and applicable local rules rather than assuming intent from amount alone.
Example: A business makes repeated cash deposits of similar size at several locations. The analyst compares the pattern with its normal receipts and reviews the wider account activity.
Common misconception: Deposits below a legal reporting threshold do not by themselves establish structuring. Thresholds and laws are jurisdiction-specific, and intent cannot be inferred from amounts alone.
33. Layering and obscured flows
Suspicious activity identification
Layering refers to movement through transactions or intermediaries that may make the origin, ownership, or destination of funds harder to understand. Complex flows can be a warning sign, but complexity may also reflect legitimate commercial arrangements. Review the sequence, relationships, economic rationale, and information gaps before interpreting the pattern.
Example: Funds pass through several accounts before reaching a final recipient with no obvious link to the customer. The analyst maps the flow and checks available reasons for each transfer.
Common misconception: Multiple transfers are not automatically laundering. A conclusion should be based on the flow and supporting facts, not complexity alone.
34. Rapid movement of funds
Suspicious activity identification
Rapid movement describes funds entering and leaving an account over a short period, sometimes with little apparent retention or economic purpose. Timing can help identify pass-through behavior, but it must be assessed alongside customer activity, counterparties, and transaction purpose. The relevant question is whether the speed and sequence make sense in context.
Example: A personal account receives a sizeable transfer and sends most of it to unrelated recipients soon afterward. The analyst checks the customer’s explanation and available evidence of the recipients’ relationship.
Common misconception: Speed alone does not establish suspicious activity. Legitimate settlements and scheduled payments can move quickly; examine the full sequence and the account’s expected use.
35. Potential money-mule patterns
Suspicious activity identification
A potential mule pattern involves an account used to receive and move funds for another party, sometimes through multiple accounts or recipients. Relevant indicators may include pass-through activity, unrelated incoming payments, rapid onward transfers, or behavior inconsistent with the account holder’s circumstances. These indicators call for investigation, not an assumption about the account holder’s knowledge or intent.
Example: A personal account receives payments from multiple unrelated senders and forwards most funds to new recipients. The analyst checks transaction links and any available customer context.
Common misconception: An account with mule-like activity does not prove that its holder knowingly participated. Separate observed conduct from any claim about intent or criminal responsibility.
36. Activity involving possible fraud proceeds
Suspicious activity identification
Fraud-related indicators may include unexpected incoming funds, rapid dispersal, unusual refunds, or payments inconsistent with the customer’s normal activity. Transaction monitoring can identify patterns that merit coordination with relevant internal teams, but an analyst should not declare fraud based solely on an unusual payment. Record the observable facts and follow referral procedures.
Example: A customer receives several unexpected credits and quickly sends the funds to different accounts. The analyst documents the sequence and routes the concern through the appropriate internal process.
Common misconception: Unusual credits do not establish that fraud occurred or that the customer caused it. Consider whether the customer may be a victim, intermediary, or legitimate recipient.
37. Cyber-related transaction indicators
Suspicious activity identification
Cyber-related activity can produce distinctive transaction patterns, including rapid movement through accounts, unusual payment channels, or clusters of related recipients. Such behavior may overlap with other typologies and may not be visible from a single transaction. Analysts should preserve relevant records, use authorized internal expertise, and avoid technical claims that the evidence does not support.
Example: Several customers send funds to accounts that later transfer them onward in a coordinated pattern. The analyst records the linked transactions and consults the designated internal team.
Common misconception: An unusual device, channel, or payment pattern alone does not prove a cyberattack. Distinguish transaction evidence from technical attribution and follow established referral channels.
38. Trade-based activity indicators
Suspicious activity identification
Trade-based money-laundering indicators concern possible misuse of trade transactions to disguise value or movement of funds. Inconsistencies among payments, counterparties, goods, shipping, and the customer’s business may warrant review. Individual indicators can have ordinary explanations, so analysts should compare related records and use appropriate trade expertise when available.
Example: A business makes payments that appear inconsistent with its described trade activity. The analyst identifies the mismatch and seeks relevant transaction or account records through approved channels.
Common misconception: A complex or unusual international payment is not itself proof of trade-based laundering. Identify the specific discrepancy and assess whether available context explains it.
39. Cash activity in context
Suspicious activity identification
Cash activity can be relevant because it may be difficult to trace, but its significance depends heavily on the customer’s business, location, history, and transaction pattern. Compare deposits and withdrawals with expected operations and related account flows. The purpose is to identify unexplained behavior, not to treat cash use as inherently suspicious.
Example: A cash-intensive café deposits more during a local festival. The analyst compares the timing and amounts with available business context and the customer’s historical pattern.
Common misconception: Cash deposits do not automatically indicate illicit funds. Conversely, a cash-based business profile does not explain every pattern; investigate material deviations.
40. Third-party payments
Suspicious activity identification
Payments involving third parties may be consistent with an ordinary business or personal arrangement, or they may obscure who benefits from or controls funds. Assess whether the third party has a plausible connection to the customer and whether the payment purpose fits available records. Preserve distinctions between payer, account holder, recipient, and ultimate beneficiary.
Example: A business receives repeated payments from entities not identified in its customer file. The analyst checks the stated business model and available transaction details for a reasonable connection.
Common misconception: A third-party payment is not automatically suspicious, and a transaction description alone may not establish its purpose. Verify the relationship where relevant and document uncertainty.
60 concepts to know and apply 41–50
41. Geographic context
Suspicious activity identification
Geographic information may inform risk assessment when considered with the customer, product, transaction route, and relevant institutional or legal context. A location alone does not establish suspiciousness or justify a blanket outcome. Analysts should use current, reliable sources and assess the actual activity and exposure involved.
Example: A customer begins making transfers to a new region. The analyst checks the transaction purpose, counterparties, and customer context rather than relying on location alone.
Common misconception: Do not treat a country or region as proof of wrongdoing. Geographic risk is contextual, and monitoring decisions should be proportionate to the specific facts.
42. Activity inconsistent with a business model
Suspicious activity identification
A mismatch between account activity and a customer’s stated business model can be a useful indicator, especially when the scale, counterparties, or flow of funds lacks an apparent connection to operations. Confirm what the institution knows about the business and whether information may be outdated before interpreting the mismatch.
Example: A small local service business begins receiving many payments from unrelated overseas parties. The analyst checks the business profile and available explanation for the change.
Common misconception: A business profile is not a rigid ceiling on legitimate activity. Growth or a new service may explain change, but the explanation should be assessed rather than assumed.
43. Networks and connected activity
Suspicious activity identification
Network analysis looks for meaningful connections among customers, accounts, counterparties, and transactions. It can reveal coordinated flows or recurring intermediaries that isolated reviews miss. A network pattern is only as reliable as the links used to build it, so analysts should distinguish confirmed relationships from inferred associations and explain the basis for each.
Example: Several accounts send funds to the same recipient and then receive transfers from connected businesses. The analyst maps the observed links and checks whether they have a documented purpose.
Common misconception: A common counterparty does not necessarily mean customers are coordinating. Avoid overstating an inferred network and verify important links where possible.
44. Anomalies and repeated behavior
Suspicious activity identification
An anomaly is a departure from an expected or comparative pattern; repeated behavior may make an anomaly more meaningful or help explain it. Reviewers should distinguish a one-off event from a recurring sequence and consider whether either reflects a known change in circumstances. Pattern strength comes from context and evidence, not repetition alone.
Example: A customer makes one unusual transfer, then repeats a similar sequence over several weeks. The analyst compares the events and investigates whether the pattern has an explained purpose.
Common misconception: Repeated activity is not automatically suspicious, and a single event is not automatically harmless. Assess how the pattern relates to the customer and what evidence supports an interpretation.
45. Combining indicators without overclaiming
Suspicious activity identification
Multiple indicators can make a concern more compelling when they are independent, relevant, and supported by evidence. Simply counting red flags is not a sound method: indicators may be related, weak, or explained by the same legitimate circumstance. Explain how the facts fit together and identify what remains uncertain.
Example: Rapid transfers, unrelated senders, and a profile mismatch appear in one review. The analyst assesses their connections and records whether any verified context explains the combined pattern.
Common misconception: Several weak or duplicative indicators do not automatically prove suspicion. Evaluate the quality and relationship of the facts rather than treating a checklist total as a conclusion.
46. Closing an alert
Escalation and reporting
Closure is appropriate when the review, under the institution’s process, supports ending that alert without further action at that time. The rationale should identify what was reviewed, why the activity is sufficiently explained or not otherwise actionable, and any control issue requiring separate attention. Closure does not assert that no risk exists anywhere.
Example: Records confirm that an alert reflects regular payments under a documented arrangement. The analyst records the relevant evidence and closes the alert through the normal workflow.
Common misconception: Closing is not the same as proving that activity is risk-free. State the scope and basis of the decision, and route any unresolved systemic concern appropriately.
47. Continued monitoring
Escalation and reporting
Continued monitoring may be appropriate when activity is unusual but the current evidence does not support a stronger disposition, and later behavior could clarify the pattern. A useful monitoring decision defines what should be watched, why further observation matters, and how relevant new information will be handled under policy.
Example: A new payment pattern has no clear explanation, but available evidence is limited. The analyst documents the uncertainty and follows the institution’s process for a future review trigger.
Common misconception: Monitoring should not become an indefinite substitute for a decision. Record the reason, scope, and review approach, and escalate if subsequent evidence changes the assessment.
48. Internal escalation and analyst authority
Escalation and reporting
Internal escalation routes a concern to the person or function authorized to assess the next step, such as a specialist reviewer or designated decision-maker. Frontline analysts should present evidence and a reasoned recommendation within their role, not make decisions reserved to others. Follow institutional channels and preserve a clear handoff record.
Example: An analyst identifies unexplained rapid movement and submits the case, transaction map, and unresolved questions to the designated escalation team.
Common misconception: An analyst should not claim to have approved or made a filing decision unless that authority is assigned. Escalate through the proper route and distinguish recommendation from decision.
49. Reasonable suspicion as an assessment
Escalation and reporting
Suspicion assessment considers whether the available facts warrant internal escalation and, where applicable, whether a report may be required under the relevant jurisdiction’s law. The legal reporting threshold and decision process vary by jurisdiction and role; internal policy can govern routing but does not replace applicable law. Analysts should document the factual basis and uncertainties, then use the designated process rather than treating one red flag as a universal test.
Example: Several transactions remain unexplained after review, and the pattern appears inconsistent with the documented account purpose. The analyst summarizes those facts for the authorized reviewer.
Common misconception: There is no single worldwide formula in this guide for deciding when suspicion is reportable. Apply the relevant jurisdictional requirements and internal procedures through the proper decision-maker; internal procedures do not substitute for applicable law.
50. SAR or STR reporting roles
Escalation and reporting
Suspicious activity or transaction reporting processes generally involve internal review and designated responsibilities, which may differ by institution and jurisdiction. An analyst’s contribution is to identify and document relevant activity and route it appropriately. The final decision, submission, and required content must follow applicable law and assigned institutional authority.
Example: An investigator prepares a factual case summary and sends it to the team responsible for assessing whether a report is required under local rules.
Common misconception: Do not assume every alert requires a report or that every analyst has authority to submit one. Follow the applicable process and keep reporting decisions with designated roles.
60 concepts to know and apply 51–60
51. Tipping-off risk
Escalation and reporting
Tipping-off concerns arise when disclosure could improperly reveal that a suspicion or report is being considered or has been made. The scope and timing of legal restrictions vary by jurisdiction and circumstances; they do not necessarily begin only when a case is escalated. Follow local law and institutional guidance when communicating with a customer, and use approved procedures when a case is under review.
Example: After a case is referred for reporting review, a relationship manager asks to explain the referral to the customer. The analyst consults the designated escalation owner before any contact.
Common misconception: Do not assume that every routine customer question is prohibited, that any explanation is safe, or that restrictions begin at one universal stage. Check the timing, content, local requirements, and approved communication process.
52. Factual reporting narratives
Escalation and reporting
A report or escalation narrative should present relevant transactions, relationships, timing, customer context, and the basis for concern clearly and accurately. It should separate observed facts from analysis, avoid unsupported accusations, and follow applicable content requirements. The analyst’s notes should make it possible for an authorized reviewer to understand the case without reconstructing the investigation from scratch.
Example: A case summary describes incoming and outgoing transfers, the observed timing, known account purpose, and the unresolved links that led to escalation.
Common misconception: A narrative should not state an unverified typology as fact. Describe what the records show and explain why the pattern may warrant review.
53. Effective case handoffs
Escalation and reporting
A handoff transfers a case with enough context for the next reviewer to continue efficiently and understand what has been done. It should identify the issue, evidence reviewed, key findings, open questions, relevant deadlines or workflow considerations under policy, and the requested action. Clear ownership reduces missed steps and duplicated work.
Example: The analyst sends the escalation team a concise summary, links to supporting records, prior case references, and a list of questions still unresolved.
Common misconception: Forwarding a case without a summary is not a complete handoff. The next reviewer should not have to guess why the matter was escalated or what remains to be done.
54. Confidentiality and controlled access
Escalation and reporting
Investigation information should be handled through authorized systems and shared only with people who have a legitimate role, subject to applicable law and institutional policy. Proper access supports confidentiality, consistent records, and a reliable audit trail. Analysts should avoid informal discussions or storing sensitive case material in unapproved locations.
Example: A reviewer needs input from a specialist team, so the analyst shares the relevant case details through the approved case-management channel.
Common misconception: A colleague’s interest does not automatically authorize access to a sensitive case. Confirm role-based permissions and use approved communication and storage methods.
55. Jurisdiction-specific reporting requirements
Escalation and reporting
Reporting rules, deadlines, forms, and confidentiality obligations may differ across jurisdictions and can depend on the institution and facts. An analyst should not transfer a rule from one country to another without verification. When a precise requirement matters, consult current local law, official guidance, and the institution’s designated compliance procedures.
Example: A cross-border case involves activity booked in more than one jurisdiction. The analyst flags the issue for the compliance function rather than assuming one filing timeline applies everywhere.
Common misconception: FATF standards are international recommendations, not automatically domestic law. Do not present a threshold or filing deadline as universal without an established jurisdiction and source.
56. Escalation quality review
Escalation and reporting
Quality review of escalations checks that the case contains relevant facts, a coherent analysis, appropriate routing, and a clear distinction between evidence and inference. It can identify omissions that affect decision-making and recurring training needs. Review standards should be applied consistently without turning a checklist into a substitute for judgment.
Example: A quality reviewer notes that a referral names rapid transfers but omits the counterparties and supporting transaction sequence. The analyst adds the missing factual context.
Common misconception: A technically completed form may still be a weak escalation. Review whether the evidence and reasoning are understandable and sufficient for the next decision-maker.
57. Management information
Escalation and reporting
Management information summarizes monitoring and investigation activity to help responsible leaders understand workload, outcomes, emerging patterns, and control performance. Useful measures need consistent definitions and appropriate context; raw alert counts alone can be misleading. Analysts may contribute accurate case data, while interpretation and oversight belong to the relevant control owners.
Example: A team reports a rise in alerts from one scenario alongside review outcomes and identified data issues, giving managers a fuller view than volume alone.
Common misconception: A high alert count does not necessarily mean risk increased, and a low count does not prove effective detection. Interpret metrics with data quality and process context.
58. Control feedback from case outcomes
Escalation and reporting
Case outcomes can reveal where monitoring inputs, procedures, training, or data controls need attention. Feedback should describe the recurring issue and provide suitable examples through established governance channels. Analysts can identify and report problems, but changes to controls should be assessed and approved by the responsible owners.
Example: Several investigations identify the same outdated customer category as a source of unnecessary alerts. The analyst submits the pattern to the team responsible for customer-data controls.
Common misconception: Closing an individual alert does not fix a recurring control defect. Conversely, one unusual case may not justify changing a system; share evidence for governed assessment.
59. Ongoing handling after escalation
Escalation and reporting
Escalation does not necessarily end all monitoring or operational responsibilities. The institution’s process may require continued review, record preservation, or coordination while an authorized decision is pending or after it is made. Analysts should follow assigned instructions and avoid independently changing account treatment or customer contact outside their authority.
Example: A case is under internal review, while a new alert identifies related activity. The analyst links the new information to the case and follows the escalation team’s instructions.
Common misconception: Do not assume that escalation means close all related alerts or take independent customer action. Follow the assigned workflow and route new evidence to the responsible owner.
60. Audit trail and decision traceability
Escalation and reporting
An audit trail records what was reviewed, by whom, when, what decision was made, and the basis for that decision, in accordance with institutional procedures. Traceability supports later quality review, continuity, and accountability. Records should be accurate, contemporaneous where practicable, and maintained in approved systems rather than reconstructed from memory.
Example: A reviewer records the evidence checked, the reason for escalation, the recipient, and the next action in the case-management system.
Common misconception: A final disposition without a record of its reasoning is difficult to verify or hand off. Do not rely on informal messages or memory as the case’s only decision record.
A six-step study plan
Official information and scope
This is original, independent exam-preparation material; it is not an ACAMS publication and does not reproduce actual or recalled exam questions. The certification scope and exam details are based on the ACAMS CTMA certification and associate-certification information, checked on 2026-10-11: https://www.acams.org/en/certifications/ctma and https://www.acams.org/en/help-center/associate-certifications. Confirm current requirements with ACAMS. This guide does not treat FATF standards as domestic law or state jurisdiction-specific reporting rules as universal.