1You receive an alert on a customer whose profile you know nothing about. Walk me through your first steps.

I'd start with the customer, not the transactions, because without knowing what is normal I can't judge whether anything is abnormal. So I'd read the profile first: occupation or business type, declared income or turnover, expected activity, geography, risk rating, and how long the relationship has existed.

Then I'd look at why the alert triggered — which scenario, on what data, and what threshold was crossed. That tells me what the system thought was unusual.

Only then would I look at the transactions themselves: amounts, counterparties, timing, geography, and how they sit against the declared pattern.

I'd also check history — previous alerts, previous escalations, whether this pattern has been reviewed and closed before. Closing something as normal that was escalated three months ago would be a serious miss.

Working in that order matters. Analysts who open the transaction list first tend to anchor on the numbers and lose the context that actually explains them.

2An alert triggers on a customer whose activity has been consistent for five years. Do you close it quickly?

Not quickly, though the history is relevant context. A long consistent record makes a legitimate explanation more likely, and I'd weigh that.

But consistency isn't a clearance. Criminals deliberately use established accounts precisely because they attract less scrutiny, and account takeover or a change in who controls the account produces exactly this profile — a long clean history followed by something out of pattern.

So I'd focus on what changed. Is this a scale increase in the same behaviour, or genuinely different behaviour? New counterparties, new geographies, a different transaction type, or a change in timing patterns all read differently from a larger version of the usual activity.

I'd also check whether anything changed on the customer side — a new signatory, a change in ownership, updated contact details, or a recent password reset if that data is available.

If the change is explicable and consistent with their business, I'd close with reasoning. If I can't explain the shift, tenure doesn't resolve it.

3The customer's explanation for an alerted transaction sounds plausible but you cannot verify it. What do you do?

Unverified is not the same as verified, and I'd be careful not to let a comfortable-sounding story close the case.

First I'd try to verify it. If they say the funds are proceeds of a property sale, there may be a completion statement, a solicitor's client account as the sender, or land registry records. Most explanations leave some trace, and a customer with a genuine one can usually point to it.

If evidence genuinely isn't obtainable, I'd assess how material the gap is. An unverified explanation for a modest transaction on a low-risk customer is different from an unverified explanation for a large payment on a high-risk one.

I'd also test internal consistency — does the explanation fit the amount, the timing, the sender, and what we already know about the customer?

I'd document the explanation, that it could not be corroborated, and my reasoning. Where it remains unexplained on a material point, that supports escalation rather than closure.

4You are 80 percent confident an alert is a false positive. Do you close it?

It depends what the remaining 20 percent consists of, and I'd be uncomfortable framing it as a percentage at all.

If the residual doubt is generic — I can't rule out that any customer might be doing something wrong — that's not a reason to escalate, because that doubt exists on every file.

But if the 20 percent is a specific unresolved element — a counterparty I couldn't identify, a payment reference that doesn't fit, an amount that doesn't reconcile — then it isn't a false positive at all. It's a partially investigated alert, and I'd resolve that element before deciding.

So my approach would be to name what the doubt is. If I can articulate it, I investigate it. If I can't, and everything checks out against the profile with evidence, I'd close with clear reasoning.

What I wouldn't do is close on balance of comfort. The standard is whether the activity is explained, not whether it's probably fine.

5An alert involves a product or industry you do not understand. What do you do?

Research it and ask, rather than guess. Guessing produces errors in both directions — I might close something genuinely suspicious because I don't recognise the pattern, or escalate something entirely normal for that sector.

I'd start with what's available internally: procedures, sector guidance, or previous cases on similar customers. Often someone has already worked this type of business.

Then I'd ask colleagues or a subject matter expert. In most teams someone has sector experience, and a five-minute conversation is faster and more reliable than an hour of speculation.

Externally I'd look at how the industry normally operates — typical payment cycles, counterparty types, whether cash or international transfers are normal.

What I'd record is what I learned and where it came from, so the reasoning is transparent and the next analyst benefits.

And I'd rather flag that a case needs more time than close it on a shallow understanding — that's the honest position and it's usually respected.

6You have 30 alerts due today and can properly investigate 20. How do you handle it?

I'd prioritise by risk rather than by order of arrival, and be transparent about the shortfall rather than absorbing it.

Prioritisation would consider customer risk rating, transaction value, whether there's sanctions adjacency, whether the customer has prior escalations, and any regulatory deadline attached.

Then I'd complete those 20 properly and flag the remaining 10 to my supervisor with the reason, rather than rushing all 30 to a standard that wouldn't survive quality review.

That's the key point: 30 poorly reviewed alerts is worse than 20 done well and 10 reported as outstanding. Rushed closures create false assurance — the file says reviewed when nothing meaningful happened.

If it were a one-off peak I'd manage it. If it's persistent, I'd raise it as a capacity issue, because a chronic gap between volume and capacity is a control problem rather than a personal workload problem.

Unmanaged backlogs are among the most common findings in enforcement actions.

7You discover a previous analyst closed a similar alert on the same customer six months ago. Does that change your assessment?

It's relevant but not determinative, and I'd read the previous case rather than just noting its existence.

What I'd look for is the reasoning. If the earlier analyst investigated properly, obtained an explanation, verified it, and documented why it was legitimate, that's genuinely useful — the same explanation may apply and I'm not starting from nothing.

If the closure was thin — a one-line note with no evidence — then it tells me little, and I'd treat this as effectively unexamined.

The more important question is what the repetition means. A pattern recurring after being reviewed and explained may be entirely consistent with the business. But a recurring pattern that was never properly explained is a different picture, and the repetition itself becomes evidence.

I'd also consider whether the two alerts together reveal something neither showed alone.

If I concluded the earlier closure was wrong, I'd say so and flag it, rather than quietly reaching the opposite conclusion.

8A customer contacts you directly asking why their payment is being reviewed. What do you say?

I'd follow the firm's approved wording and say nothing beyond it. Typically that means referring to standard internal checks that apply to transactions from time to time, and that we'll be in touch as soon as they're complete.

What I would not do is improvise. Saying anything that suggests a report has been made or is being considered risks tipping off, which is a criminal offence in most jurisdictions — and improvised reassurance is exactly how people stray into it.

I'd also be careful about tone. Being evasive or unusually formal can itself signal something, so a calm, routine response is better than a defensive one.

If they press for detail, I'd hold the line politely and offer to escalate their query to the relationship team rather than expanding my own explanation.

I'd record the contact and what was said, because the fact that a customer chased a delayed payment can itself be relevant, and the record protects me on the tipping-off point.

9An alert shows a large payment to a charity in a high-risk jurisdiction. Suspicious?

Not on its own, and I'd be careful here because this is an area where over-reaction causes real harm. Legitimate humanitarian work happens in high-risk and conflict-affected regions by definition.

I'd start with the customer — is charitable giving consistent with their profile and history? A customer who has donated regularly to related causes reads very differently from one making an unprecedented large transfer.

Then the recipient: is it a registered charity, does it have a genuine operational presence, and does it appear on any screening lists?

The specific risk with charitable flows to high-risk regions is diversion at the delivery end rather than the donor's intent, so I'd look at whether the organisation is established and accountable.

Concerns would be an unregistered recipient, funds going to individuals rather than an organisation, or a donation inconsistent with the customer's means.

Absent those, I'd document the assessment and close. Treating charitable giving as inherently suspicious is exactly the de-risking regulators criticise.

10A customer's transactions are entirely normal in isolation but the pattern feels wrong. How do you approach that?

I'd do the work of turning that feeling into something specific, because unease alone can't be escalated or acted on.

Usually the discomfort reflects something identifiable I haven't articulated. Common candidates: the timing is too regular for genuine commercial activity, or too irregular for salary; amounts are just below a threshold consistently; funds arrive and leave with nothing retained; counterparties have no evident connection to the stated business; or the activity is technically consistent but economically pointless.

That last one matters. A transaction can be entirely normal in form while making no commercial sense — money moving in a circle, or costs incurred for no benefit.

So I'd map the flows visually if needed, and ask what the economic purpose is.

If I can name it, I investigate it and escalate with specifics. If after that effort I still can't articulate anything, I'd discuss it with a colleague rather than either escalating on instinct or closing to move on.

11You find the customer's account was accessed from an unusual location shortly before the alerted transaction. What does that add?

It shifts my thinking toward account takeover or third-party control, which is a different investigation from ordinary laundering.

If the customer's account is being operated by someone else, the transaction may not be theirs at all — they may be a fraud victim rather than a subject. That changes both the assessment and the response, since the customer might need protecting rather than reporting.

So I'd look at the wider access pattern: is this a one-off or has activity been coming from that location for a while, were there recent credential or contact detail changes, and does the transaction behaviour change at the same point.

A password reset, a new device, a changed phone number and then an unusual payment is a classic takeover sequence.

Travel is the obvious innocent explanation, and I'd check whether other activity supports that.

Given the possibility of fraud in progress, I'd escalate quickly rather than complete a leisurely investigation — and involve the fraud team, since this may need both.

12An alert relates to a transaction that has already settled and cannot be recovered. Is there still value in investigating?

Yes, and I'd push back on any suggestion otherwise. Recovering funds isn't the purpose of transaction monitoring.

The purpose is intelligence and control. Even where funds have gone, the investigation may reveal an ongoing pattern, identify a network involving other customers, establish that the relationship should be reassessed, or produce a suspicious activity report that contributes to law enforcement intelligence.

A great deal of what FIUs use comes from reports about activity that already happened.

Practically I'd investigate as normal, with particular attention to whether the pattern is continuing and whether other accounts show it.

The one thing settlement changes is urgency around prevention — there's no payment to hold. But it doesn't reduce the reporting obligation, and closing an alert because the money has gone would be a serious error.

If the pattern suggests more transactions are coming, that's actually a reason to work it faster.

13Your investigation is complete but you cannot decide between closing and escalating. What do you do?

I'd escalate, and I'd frame it as a referral for decision rather than an assertion of suspicion.

The escalation route exists precisely for cases sitting on the line. Closing something I genuinely can't resolve puts my uncertainty into a file marked "no concerns," which misrepresents the position.

What matters is how I escalate. I'd set out what I found, what I could and couldn't verify, the arguments each way, and why I couldn't reach a conclusion. That's far more useful to an MLRO than either a bare escalation or a confident position I don't actually hold.

I'd also be honest about the limits — what evidence would have resolved it and why it wasn't available.

One caveat: if I'm escalating a high proportion of cases, that's a signal in itself — either the scenarios are poorly tuned, or I need more training on where the threshold sits. I'd want to know which.

14You realise mid-investigation that the alerted activity is only part of a longer pattern predating the alert period. What now?

I'd expand the review period to follow the conduct rather than restricting myself to the alerted window.

The alert window is a system artefact — it reflects when a threshold was crossed, not when the behaviour began. If the pattern runs back two years and I only look at two months, I'll materially understate what's happening, and the two-month view may look far less significant.

So I'd map the full period and quantify the total, because scale often changes the assessment entirely.

I'd also check whether earlier alerts fired on this pattern and were closed. If they were, and I now think the pattern is suspicious, those closures need flagging — both because the earlier assessment may have been wrong and because it suggests a scenario or training gap.

If no alerts fired across that period despite the pattern, that's a detection gap worth raising separately from the case itself.

15A customer makes fifteen cash deposits of 9,500 over three weeks where the reporting threshold is 10,000. Your assessment?

This is textbook structuring and I'd treat it as a strong indicator rather than a coincidence. Fifteen deposits consistently just below a threshold is not how legitimate cash arises — genuine takings vary.

I'd confirm the pattern precisely: exact amounts, dates, locations, and whether deposits were split across branches or channels, which strengthens it further.

Then I'd check the customer profile. Even for a cash business, this pattern is odd — real takings fluctuate with trade, and a business would normally deposit actual daily totals rather than a repeated round-ish figure below a line.

The total also matters: roughly 142,500 over three weeks needs to make sense against declared turnover.

There's essentially no innocent explanation for amounts clustering just under a threshold repeatedly, though I'd still give the customer an opportunity if our process allows contact.

I'd escalate with the pattern documented clearly, and I'd expect this to proceed to a report.

16A restaurant's cash deposits double over three months. Suspicious?

Not necessarily, and this is where testing the innocent explanation properly matters.

Restaurants have genuine reasons for cash increases: a second site, extended hours, a refurbishment reopening, seasonal trade, a change in menu or pricing, or simply better business.

The most useful test is the relationship between cash and card. Most restaurants take both, and genuine growth normally lifts both together. If card revenue is flat while cash has doubled, that's the pattern that concerns me — because it means more cash without more customers.

I'd also look at supplier payments and payroll. A restaurant genuinely doing twice the trade buys more stock and usually pays more staff. Revenue rising with costs flat is difficult to explain.

Deposit timing helps too — daily banking consistent with trading days is normal; large round deposits at irregular intervals is less so.

If cash and card moved together and costs rose proportionately, I'd document that and close it as evidenced growth.

17A customer deposits cash at multiple branches on the same day. What does that suggest?

It's a recognised structuring indicator, because the obvious purpose of splitting deposits across locations is to avoid aggregation and reduce the chance any one branch notices.

That said, I'd check the innocent explanations. A business with multiple sites may legitimately bank locally at each — a retail chain does this routinely. Someone travelling for work might bank wherever they are.

So I'd look at whether the customer has operations near those branches, and whether this is a consistent long-term pattern or a recent change.

The concerning version is deposits at several branches with no operational connection to those locations, particularly if the individual amounts are below reporting or attention thresholds while the aggregate is substantial.

I'd also check whether different people are making the deposits, since that adds a smurfing dimension.

If there's no operational explanation and the amounts pattern below thresholds, I'd escalate. If the branches map to genuine sites, I'd document that and close.

18Several different individuals deposit cash into the same account across a short period. Your read?

This is a smurfing pattern and it concerns me more than a single customer structuring, because it implies coordination.

I'd establish who the depositors are and whether there's any connection to the account holder. Some explanations are legitimate — a business where staff bank takings, a club or association collecting subscriptions, or family contributing to a shared expense.

So the account type matters. A community organisation receiving deposits from members is entirely normal; a personal account receiving cash from a dozen unconnected people is not.

I'd look at whether the depositors appear elsewhere in our records, whether the same individuals also deposit into other accounts, and whether the amounts follow a pattern suggesting instruction rather than independent activity.

What happens to the money next is equally important. Deposits accumulating and then leaving in one transfer, or being withdrawn as cash, suggests collection rather than legitimate receipts.

Absent a clear organisational explanation, I'd escalate — and I'd look for related accounts showing the same structure.

19A customer with no declared business receives regular cash deposits from a single source. How do you assess it?

The single source is actually the useful feature here, because it narrows the innocent explanations considerably.

Regular deposits from one person often have legitimate explanations — maintenance payments, family support, rent from a lodger, or repayment of a loan. These are common and unremarkable.

So I'd want to know who the depositor is and what the relationship is. If the customer says it's rent, does the customer own property? If it's family support, is the depositor a relative?

What would concern me is cash specifically. Rent and family support usually move by transfer; cash suggests the payer is avoiding a record, which raises the question of where their money comes from.

I'd also assess scale against the customer's known circumstances. Modest regular amounts read very differently from substantial ones.

If the explanation is coherent and proportionate, I'd document and close. If the customer can't explain who is paying them or why in cash, that's escalation territory.

20A car wash deposits far more cash than similar businesses of its size. What do you do?

Car washes are a known higher-risk cash business, so I'd approach this with that context but still test it properly.

I'd benchmark against realistic capacity. A car wash can only process so many vehicles in a day — site size, number of bays, staff, and opening hours all constrain it. If the deposits imply washing more cars than the site could physically handle, that's a concrete, evidenced concern rather than a general suspicion.

I'd also look at costs. Genuine volume means water, electricity, consumables and staff. Revenue rising with flat costs is difficult to explain, and payroll is often the clearest tell.

Card versus cash ratio is useful too, though car washes legitimately skew cash more than most sectors.

Legitimate explanations exist — an additional site, contract work for a dealership or fleet, or valeting services at higher prices. Each is evidenceable.

Without an explanation supported by capacity and cost data, I'd escalate. The capacity argument is what makes this case strong.

21A customer withdraws large amounts of cash regularly with no apparent purpose. Concern?

Cash withdrawals get less attention than deposits, but they matter — they're how funds leave the traceable system, and that's the point at which the trail ends.

I'd look at the customer's profile and whether cash use is consistent with it. Some businesses genuinely operate in cash: those paying day labour, buying from cash-only suppliers, or operating in cash-dominant economies. Some individuals prefer cash for cultural or generational reasons.

Scale and pattern matter. Regular round-sum withdrawals just below a reporting threshold read very differently from variable amounts consistent with living expenses.

I'd also look at where the money comes in from. Funds arriving by transfer from multiple sources and leaving as cash is a classic layering-to-extraction pattern.

The concerning combination is unexplained credits followed by prompt cash extraction, with no evident business need.

If the customer can explain the cash need and it fits their profile, I'd document and close. If not, I'd escalate.

22Cash deposits stop abruptly after you contact the customer about them. What does that tell you?

It's meaningful and I'd document it carefully, though I'd be measured about what it proves.

There's an innocent reading: a customer told their banking is being reviewed may reasonably change behaviour to avoid inconvenience, or may have been unaware their pattern looked unusual.

But the more concerning reading is that contact alerted them, and activity moved elsewhere. Cessation immediately following an enquiry is a recognised indicator.

So I'd check whether the money genuinely stopped or simply changed form — smaller amounts, different channel, different branches, or transfers replacing cash. Behaviour that adapts rather than ceases is more telling than behaviour that stops.

I'd also check for related accounts, since activity often migrates to another entity or individual.

Importantly, this raises a process question: if my contact prompted the change, was that contact appropriate? Where suspicion exists, enquiries can prejudice an investigation, so I'd want guidance on customer contact going forward rather than treating it as routine.

23A customer asks to make a deposit just under the reporting threshold and asks whether that avoids paperwork. What do you do?

This is close to an admission of intent, and I'd treat it very seriously.

In most jurisdictions structuring is an offence in itself, separate from whatever the money represents. A customer explicitly asking how to avoid a report has effectively stated the purpose.

I would not advise them, confirm thresholds, or help structure the transaction. I'd also avoid indicating that the request itself is a problem, because that risks tipping off.

I'd process or decline the transaction per procedure and document the exact words used, in quotation marks where possible. The precise wording matters enormously here — "does under ten thousand avoid the form" is very different from "will this be delayed."

Then escalate immediately. This isn't something to note and continue with.

I'd also check whether the customer has made prior deposits fitting the pattern, since the request suggests knowledge they've likely acted on before.

24A business customer's cash deposits are perfectly consistent every week — identical amounts. Suspicious?

Yes, counterintuitively. Perfect consistency in cash takings is unnatural, and it's one of those patterns that looks reassuring until you think about it.

Genuine trade fluctuates — weather, holidays, weekdays versus weekends, seasonality. A business banking exactly the same figure every week isn't reflecting real trading; it's depositing a decided amount.

That's characteristic of laundering, where a fixed sum is placed regularly, sometimes mixed with genuine takings.

I'd check whether the amounts are truly identical or merely similar, since some regularity is normal for a stable business. Identical to the pound is the concerning version.

I'd compare against card takings, which should show natural variation even if cash doesn't, and against the business type — some sectors are more stable than others.

A subscription-based or contract business might legitimately show consistency, so context matters.

Absent an explanation for that regularity, I'd escalate. It's a subtler indicator than structuring but a well-recognised one.

25Cash deposits are made by someone other than the account holder. How do you approach it?

I'd want to establish who they are and on what basis they're depositing, because third-party deposits raise the question of who actually controls the funds.

Legitimate explanations are common: an employee banking business takings, a family member helping an elderly or unwell relative, or a bookkeeper handling a small company's banking.

So I'd look at whether the depositor's role is consistent with the account. Business takings banked by staff is routine; a personal account receiving cash from someone unconnected is not.

The concerning versions are multiple different depositors, depositors who also pay into other unrelated accounts, or a customer who can't identify who is paying money in.

That last one is significant — an account holder unaware of who deposits into their account either isn't controlling it or is a mule.

I'd check whether the depositor appears elsewhere in our records, and whether the account holder has any evident involvement in the activity generating the cash.

26A customer deposits foreign currency cash regularly. Additional concerns?

Foreign currency adds a layer, because it raises questions about how it was acquired and how it crossed borders.

Legitimate explanations exist: a customer with overseas income, a tourism-facing business, someone regularly travelling, or a family receiving remittances in cash.

I'd assess whether the currency matches the customer's known connections. A customer with family and travel history in a country receiving that currency makes sense; one with no connection to it does not.

I'd also consider cross-border cash declaration requirements. Large amounts of physical currency moving between countries usually require declaration, so I'd want to understand how it arrived — and whether the amounts are consistent with lawful movement.

Volume matters too. Occasional leftover holiday money is different from regular substantial deposits.

The concerning pattern is regular foreign cash with no travel or business connection, particularly from higher-risk jurisdictions, since physical cash is a common way to move value outside the banking system entirely.

27A cash-intensive business suddenly shifts to almost entirely electronic payments. Does that reduce your concern?

Not automatically — it's a change worth understanding rather than a reassurance.

There are entirely legitimate reasons. Consumer payment habits have shifted substantially, businesses adopt card and app payments, and some sectors have moved almost fully electronic. A shift like this over a few years is unremarkable.

What I'd look at is the timing and abruptness. A gradual shift tracking wider trends is normal. A sudden change, particularly following an enquiry from us or a change in ownership, is more interesting.

I'd also check whether total revenue held steady. If cash disappeared and overall turnover fell correspondingly, that suggests the cash element was never genuine trade. If turnover held with electronic payments replacing cash, that supports a genuine shift.

There's also a possibility worth noting: the cash may simply have moved elsewhere, to another entity or institution, rather than ceasing.

So I'd assess it as a change in pattern requiring explanation, not as a problem resolving itself.

28You notice several unconnected customers all depositing cash in similar amounts at similar times. What now?

This is a pattern I'd escalate as a linked matter rather than working each file separately, because the connection is the finding.

Individually, each customer may look unremarkable — modest cash deposits that wouldn't alert on their own. Collectively, coordinated amounts and timing across supposedly unconnected people suggests an organised operation.

I'd map what they share: deposit locations, timing windows, amounts, whether they were onboarded around the same time, shared addresses, phone numbers or devices, and whether funds move onward to common beneficiaries.

The onward flow is often the clearest link — separate deposits converging on one destination.

I'd also check whether they share an introducer or were referred through the same channel.

Then escalate as a network case with the linkage documented, and flag it for scenario review — because if this pattern evaded detection at the individual level, the monitoring logic isn't catching coordinated behaviour, which is a broader gap worth raising.

29Funds arrive in an account and leave within hours, repeatedly, leaving almost no balance. Your assessment?

This is a pass-through or funnel pattern, and it's one of the clearer layering indicators — the account is being used to move value rather than hold it.

I'd quantify it: how quickly funds leave, what proportion of each credit moves on, and whether the balance ever accumulates. Money arriving and leaving essentially intact is characteristic; a business retaining margin is not.

Then I'd look at the counterparties on both sides. Are credits coming from many sources and leaving to few, or the reverse? Do the parties have any evident commercial relationship with the customer?

Legitimate explanations exist — payment processors, agents collecting on behalf of principals, or businesses passing through client funds. Each has a documented commercial basis I could verify.

The concerning version is an account with no such role showing this pattern, particularly where counterparties don't connect to the stated business.

I'd also check whether the customer profile ever suggested this activity — if not, that mismatch alone supports escalation.

30A customer receives funds from multiple senders and immediately transfers the total to one overseas account. Read?

This is a collection-and-forward pattern, common in mule networks and in unlicensed money transmission.

I'd look at the senders first: how many, are they connected to each other or to the customer, are the amounts similar, and do they appear elsewhere in our records. Multiple unconnected senders paying one individual is the key feature.

Then the destination: who receives it, in which jurisdiction, and is there any evident relationship.

There are legitimate versions. Someone collecting contributions for a family event or a community fund, or an informal group savings arrangement, can look similar. Those usually have identifiable social connections between the parties.

Unlicensed money transmission is also possible — someone providing informal remittance services, which is itself an offence in most jurisdictions even without underlying criminality.

The concerning version is unconnected senders, rapid consolidation, and onward transfer to a higher-risk jurisdiction with no relationship evident. That I'd escalate, and I'd check for other accounts showing the same shape.

31Two customers transfer identical amounts back and forth repeatedly. What does that suggest?

Circular flows with no net effect are economically pointless, which is what makes them suspicious — legitimate transactions accomplish something.

The usual purposes are creating apparent transaction history to support a later explanation, generating volume to obscure other flows, or manufacturing an audit trail that makes funds appear to have a commercial origin.

I'd first check whether the amounts truly net to zero or whether there's a real underlying flow with the circularity disguising direction.

Then I'd look at the relationship between the parties — common ownership, shared directors, family connection, or shared address. Circular flows between commonly controlled entities are particularly concerning because the "counterparty" isn't independent.

Legitimate explanations are limited but exist: intercompany funding and repayment, a loan drawn and repaid, or corrections of errors.

I'd ask what commercial purpose the transactions serve. The absence of a coherent answer is itself the finding, and I'd escalate on that basis.

32A customer's incoming payments all carry vague references like "services" or "consulting". Significant?

It's a soft indicator on its own but meaningful in combination, and I'd note it rather than build a case on it alone.

Vague references matter because payment narratives are one of the few pieces of context we get. Legitimate commercial payments often reference invoice numbers, contracts, or specific goods. Generic descriptors provide nothing verifiable.

"Consulting" in particular is worth attention, because it's the standard cover for payments with no deliverable — it's inherently hard to disprove.

That said, plenty of genuine businesses use loose references, and some payment systems truncate them.

So I'd look at the wider picture: do the payers connect to the customer's stated business, are amounts consistent with consulting work, is there any evidence of services delivered, and is the customer's declared activity actually consultancy?

The concerning combination is vague references, unconnected payers, round amounts, and a business that doesn't obviously provide the service described. That's when I'd seek evidence of the underlying engagements.

33Payments to a customer come from an account in a different name to the counterparty on the invoice. How do you treat it?

Third-party payment is a recognised red flag because it breaks the link between the commercial relationship and the money.

There are legitimate explanations. Group companies pay on behalf of subsidiaries, parent companies settle for group entities, factoring and invoice finance arrangements mean a finance provider pays, and agents pay on behalf of principals.

So I'd ask the customer to explain and evidence the arrangement — a group structure showing the relationship, a factoring agreement, or an assignment of the invoice.

What concerns me is a payer with no evident connection to the invoiced party, particularly if the payer is in a different jurisdiction or is an individual paying a corporate invoice.

That pattern allows funds from an unrelated source to be given a commercial appearance through someone else's genuine invoice.

I'd also check whether this is occasional or systematic. Systematic third-party payment across many transactions is much more significant than a one-off, and I'd escalate on that basis.

34A customer's account shows many small round-sum transfers to different individuals. What is your read?

Round sums to multiple individuals suggests distribution rather than commercial payment, since genuine payments usually reflect invoices, hours or negotiated amounts and rarely land on exact figures repeatedly.

I'd look at who the recipients are, whether they're connected to each other, whether they appear in our records, and whether any receive repeatedly.

Legitimate versions exist. Payroll for casual staff, expenses reimbursement, contractor payments, or distributions to family members can look like this — and payroll in particular does involve regular payments to many individuals.

So I'd check whether the customer's business would plausibly involve paying individuals, and whether there's any payroll infrastructure.

The concerning version is a customer with no evident reason to pay individuals, sending round amounts to a changing set of recipients, particularly if funds arrived shortly before from a single source.

That shape — one large credit, many small onward payments — is characteristic of distributing proceeds, and it's what I'd escalate on.

35A student account receives fifteen credits from unrelated senders in two weeks, then withdraws the total in cash. Your assessment?

This has strong mule characteristics and I'd escalate rather than expect an explanation to resolve it.

The combination is what makes it clear: multiple unconnected senders, an account profile that gives no reason to receive money from many people, rapid consolidation, and cash extraction that ends the trail.

Individually each feature might have an explanation. Together they form a recognised pattern, and mule recruitment specifically targets students because accounts are new, activity is unpredictable, and recruits often don't understand what they're participating in.

I'd map the senders and check whether they appear against other accounts, since mule networks usually involve several receiving accounts.

I'd also look at whether the account was recently opened, and whether contact details changed.

Worth noting: the customer may be a victim rather than an organiser. That doesn't change the reporting position, but it may affect how the relationship is handled, and it's a reason to be careful about direct contact.

36You identify the same beneficiary receiving funds from twelve unrelated customers. What do you do?

I'd treat this as a network case and escalate it as one, because the common beneficiary is the finding — no individual file would show it.

First I'd establish what the beneficiary is. A utility company, a landlord, a popular merchant or a government body would legitimately receive from many unconnected customers, and I'd rule that out early.

If it's an individual or an obscure entity, that's different. Twelve unconnected people paying the same private beneficiary needs explanation.

I'd look at what the twelve customers have in common — onboarding period, profile, geography, how funds arrive before being forwarded, and whether references are similar.

I'd also assess the aggregate flowing to that beneficiary, since individually modest amounts can total substantially.

Then escalate with the network mapped rather than filing twelve separate reports, because the connection is the intelligence value.

And I'd flag that our monitoring didn't surface this — beneficiary-level aggregation appears to be a detection gap.

37A dormant account reactivates with high-value activity. How do you handle it?

I'd treat it as a trigger event and act promptly, because dormant reactivation is a well-established pattern — there's no recent baseline to compare against, which is precisely why it's used.

My first concern is whether the customer still controls the account. Dormant accounts are targets for takeover, so I'd check for recent changes to contact details, credentials, or access location before assuming the activity is theirs.

Then I'd establish the source of funds and what's happening next. Money arriving and moving straight out is more urgent than money sitting.

Legitimate explanations exist: an inheritance, a property sale, a customer returning from abroad, or a business restarting after a pause.

I'd also refresh the customer file, since years of dormancy means our information is stale and the profile no longer supports meaningful monitoring.

If the source can't be explained, or the pattern is receive-and-forward, I'd escalate quickly rather than complete a leisurely review while funds move.

38A customer's transactions suddenly involve a jurisdiction they have never dealt with. Concern?

A change in geographic pattern is worth understanding, though it isn't inherently suspicious — businesses expand and people's circumstances change.

What matters is whether the new jurisdiction fits anything we know. A customer expanding into a market adjacent to their existing trade, or with a family connection there, is unremarkable. A jurisdiction with no apparent connection to their business or life is not.

The jurisdiction's own risk profile matters too — a shift toward a country on the FATF grey list or with weak controls carries more weight than a shift toward a well-regulated market.

I'd look at the counterparties there and whether they connect plausibly to the customer's stated activity, and whether the flows are one-directional.

I'd also check for a diversion pattern — payments to a country bordering a sanctioned state, or to a jurisdiction known as a transit point.

If the customer can evidence the new business relationship, I'd update the profile and risk rating rather than escalating.

39Transactions consistently occur outside the customer's normal business hours or trading days. Significant?

It's a supporting indicator rather than a finding on its own, and I'd be careful not to over-read it given how much activity is now automated and around the clock.

Where it matters is mismatch with the stated business. A retail shop generating card transactions at three in the morning, or a business banking takings on days it's closed, is inconsistent in a way that needs explaining.

Automated payments, standing orders and international counterparties in other time zones all produce out-of-hours activity legitimately, so I'd rule those out first.

The pattern I'd focus on is activity clustered at unusual times without an automation or time zone explanation, particularly if it coincides with other indicators — new counterparties, unusual amounts, or access from unexpected locations.

In takeover cases timing is often revealing, because the person operating the account isn't in the customer's time zone.

So I'd note it, check it against the business model, and use it as corroboration rather than the basis of an escalation.

40A customer makes a very large one-off payment entirely out of character. How do you approach it?

One-off large transactions often have straightforward explanations, so I'd start by asking what it relates to rather than treating scale alone as suspicious.

Property purchases, tax payments, vehicle purchases, business acquisitions, school fees and settlements all produce single large payments from otherwise ordinary accounts.

What I'd examine is where the funds came from, since a large outgoing payment usually needs a corresponding credit. If a substantial sum arrived shortly before, that credit is where the real question lies.

Then the recipient — a solicitor's client account, a car dealer or a tax authority supports the stated purpose; an individual or an offshore entity does not.

I'd assess proportionality against known income and wealth. A payment far beyond anything the customer's profile supports raises the source question regardless of the destination.

If the purpose is evidenced and the funding source is explained, I'd document and close. The out-of-character nature is a reason to look, not a conclusion.

41You find the customer's counterparty is a company you cannot verify exists. What now?

An unverifiable counterparty is a significant finding, because it undermines whatever commercial explanation rests on it.

First I'd make sure I've searched properly — registries in the right jurisdiction, alternative spellings and transliterations, trading names versus registered names, and whether it's a branch or division of another entity. Companies do exist without much online presence, particularly small ones overseas.

If it genuinely can't be found, I'd ask the customer for details: registration number, address, contacts, and documentation of the relationship such as contracts or invoices.

A customer trading with a company can normally produce that easily.

The concerning version is a customer who can't provide basic details of an entity they claim to trade with, or who provides details that don't check out.

That pattern suggests either a fictitious counterparty created to justify payments, or a relationship the customer doesn't want examined. Either way I'd escalate rather than accept the transactions on their face.

42Activity in the account maps closely to a typology in a recent FATF report. Does that settle it?

It's strong supporting evidence but I wouldn't treat it as settling anything by itself, and I'd be careful about pattern-matching too readily.

Published typologies describe how criminals have operated, which makes them genuinely useful for recognising a shape. But typologies are necessarily general, and legitimate activity can resemble them — trade finance, remittance and cash businesses all produce patterns that appear in typology reports.

So I'd use it as a lens rather than a conclusion. It tells me what to look for and which specific features distinguish the criminal version from the legitimate one.

Then I'd test those distinguishing features against this customer: does the commercial rationale hold, do counterparties check out, is documentation consistent, does the economic purpose make sense.

If the distinguishing features are present, the typology match strengthens an already evidenced case considerably, and I'd reference it in the escalation because it helps the reader.

If they're absent, the resemblance alone isn't enough.

43An import company's invoices show goods priced far above market value. What does that suggest?

Over-invoicing is a core trade-based laundering technique, because the inflated element transfers value abroad under the cover of a legitimate-looking trade transaction.

I'd verify the pricing properly rather than relying on impression — commodity prices, trade databases, or comparable transactions where available. The gap needs to be substantial and demonstrable, not marginal.

Then I'd consider legitimate explanations: specialist or bespoke goods, urgent delivery premiums, long-term contracts priced historically, bundled services, or genuinely poor commercial judgement.

What strengthens the concern is a pattern — consistent over-pricing across multiple shipments, particularly with the same counterparty or into a higher-risk jurisdiction.

I'd also look at whether the goods make sense for the buyer's business, whether shipping documents corroborate the transaction, and whether the counterparty is related to the customer.

Related parties transacting at inflated prices is a much stronger indicator than an arm's-length deal.

Where the pattern holds and pricing can't be justified, I'd escalate with the pricing evidence documented.

44A trade transaction involves goods that make no sense for the buyer's stated business. How do you handle it?

This is one of the more accessible trade red flags, because you don't need pricing expertise to see the mismatch.

I'd ask the customer to explain. There are genuine reasons — diversification, acting as an agent or intermediary, buying for a related entity, or a new business line.

What I'd want is evidence: contracts, end-customer details, or agreements showing an agency role.

The concerning version is a customer who can't explain why they're buying goods unrelated to their business, or whose explanation shifts when questioned.

I'd also consider whether the goods themselves raise separate issues — dual-use items, controlled goods, or high-value commodities frequently used to move value. Those carry export control and sanctions dimensions beyond laundering.

Where the goods are dual-use and the destination is sensitive, I'd escalate urgently rather than continue investigating, because sanctions and export control timelines are tighter.

Otherwise, unexplained goods mismatch supports escalation on its own.

45Shipping documents show a route that makes no commercial sense. Your read?

Illogical routing is a recognised indicator of diversion or origin concealment, and it's worth taking seriously because shipping is a cost-driven business — nobody routes inefficiently by accident.

I'd map the route against commercial logic. Goods travelling via a third country that adds cost and time, with no processing or consolidation there, needs explaining.

Legitimate reasons exist: consolidation hubs, transhipment through major ports, capacity constraints, or avoiding a blocked route.

The concerning versions are routing through a country bordering a sanctioned state, transhipment that breaks the documentary chain of origin, or a route where the intermediate country has no plausible connection to either party.

I'd also check whether the intermediate destination has seen unusual growth in this trade generally, since diversion often shows up as a spike in exports to neighbouring markets.

Given the sanctions dimension, I'd escalate to the sanctions team as well as through the AML route if there's any suggestion the ultimate destination is restricted.

46A company's payments do not match its stated business activity at all. What do you do?

This is a fundamental mismatch and I'd treat it as a serious finding rather than a profile update.

First I'd confirm the scale of the divergence. A consultancy occasionally paying a supplier is normal; a consultancy whose entire payment flow consists of goods purchases is not.

Then I'd ask the customer to explain, and be alert to the answer simply redefining the business to fit the payments. That's the common response, and updating our records to match is the wrong reaction — the question is why the stated activity was different.

I'd want evidence for whatever they claim: contracts, invoices, or a documented change in business model.

I'd also consider whether the account is being used by someone other than the customer, or on behalf of a third party, which would explain a complete mismatch.

Where the payments can't be reconciled to any evidenced business, I'd escalate. A company whose money doesn't match what it says it does is close to the definition of a front.

47A newly formed company immediately begins transacting at high volume. Concern?

Worth examining, though not automatically suspicious — new companies with real backing do trade immediately.

What I'd test is whether there's substance behind the volume. Contracts in place, a predecessor business, an established parent, founders with sector track record, premises, staff, and a funding source for working capital.

The funding question is often the most revealing: a new company transacting heavily needs capital from somewhere, and where that came from matters.

I'd also compare actual activity against what was declared at onboarding. Volumes far exceeding the projection suggest either the projection was deliberately understated or the account is being used for something else.

The concerning profile is a recently incorporated entity, no evident substance, high-value flows to and from unconnected parties, and a pass-through pattern.

That's a classic shell profile, and I'd escalate. Where substance is evidenced, I'd update the profile and monitor rather than escalate.

48Payments flow between several companies with the same directors, with no clear commercial purpose. What now?

Intercompany flows between commonly controlled entities aren't inherently suspicious — group treasury, cost allocation and intercompany funding are all normal.

What I'd assess is whether there's an economic purpose. Legitimate group flows correspond to something: shared costs, funding, or trading between entities that genuinely trade.

Circular flows with no net effect, or payments described as services with no evident service, are different.

I'd map the full picture — how many entities, the direction and volume of flows, and whether money ultimately enters or leaves the group from external sources. That last point matters most: internal shuffling with external funds entering at one point and exiting at another is a layering structure.

I'd also check whether each entity has genuine operations, or whether some exist only to receive and forward.

And I'd aggregate exposure across the group rather than assessing each account alone, since the connected position is the real one.

49A customer requests urgent same-day processing of a large international payment with limited documentation. How do you respond?

Urgency combined with pressure to reduce documentation is a recognised technique, so I'd be alert while recognising that genuine urgency exists in business.

I wouldn't process it outside normal requirements. Documentation standards don't flex for timing, and the combination of speed and limited paperwork is precisely how transactions get pushed through unchecked.

I'd ask what's driving the urgency and what documentation is available. Genuine cases — a completion deadline, a contractual penalty, a shipment release — usually come with supporting evidence, and customers can explain the deadline specifically.

What concerns me is vague urgency, pressure applied to me or to the relationship manager, or a customer who becomes agitated when asked routine questions.

I'd also check the destination and counterparty, since urgency into a higher-risk jurisdiction with limited documentation is a much stronger indicator.

If the requirements can't be met, the payment doesn't go. I'd escalate rather than exercise discretion under time pressure, and I'd document the pressure applied.

50An invoice supporting a payment appears to have been altered. What do you do?

I'd stop and escalate rather than seek an explanation from the customer, because a suspected falsified document changes the nature of the case.

I'd document the specific anomalies factually — inconsistent fonts, misaligned figures, a changed amount or date, mismatched totals, or evidence of digital editing. Specific observations are evidence; "looked altered" is not.

I'd also cross-check the invoice against other information: does the amount match the payment, does the counterparty match the shipping documents, does the invoice number fit any sequence we've seen from that supplier.

Innocent explanations exist — a corrected error, a reissued invoice, or poor scanning. So I wouldn't treat it as conclusive.

But an altered document supporting a payment is materially different from an inconsistent one, because it suggests deliberate misrepresentation to obtain processing.

I'd hold the payment pending review, preserve the document as received, and escalate. Where the alteration changes value or parties, that likely supports a report.

51A customer's business receives payments from a jurisdiction where it has no operations or customers. How do you assess it?

I'd start by testing whether my assumption is right. Businesses have customers in places they don't operate — export sales, online trade, or a client who relocated all produce payments from unexpected jurisdictions.

So I'd ask who the payer is and what the commercial relationship is, and look for supporting documentation: contracts, invoices, or correspondence.

What concerns me is a payer with no identifiable connection to the customer's trade, particularly if the jurisdiction is higher risk or is a known transit point for value movement.

I'd also look at the shape of the flows. Occasional export receipts are unremarkable; regular substantial payments from a country the business has no presence in, with vague references, is a different picture.

And I'd consider whether the jurisdiction is being used as a routing point rather than an origin — funds may have started somewhere else entirely.

If the relationship can be evidenced, I'd update the profile and geographic risk rating. If not, I'd escalate.

52A customer's payments consistently fall just below the level requiring additional documentation. Significant?

Yes, and it's the same logic as structuring around reporting thresholds — the consistency is what makes it meaningful rather than the individual amounts.

Genuine commercial payments reflect what was invoiced or agreed, so they land at varied amounts. Payments repeatedly sitting just under an internal documentation threshold suggest someone knows where that line is.

I'd quantify it precisely — how many payments, how close to the threshold, and over what period. A handful near the line is chance; twenty consistently just below is not.

I'd also consider how the customer would know our threshold. Sometimes it's inferred from experience — they noticed which payments triggered questions. Sometimes it suggests information from inside, which is a separate and serious concern.

Legitimate explanations are limited, though contract structures or payment schedules can occasionally produce clustering.

I'd escalate the pattern, and separately flag it for threshold review, since a threshold customers can reverse-engineer isn't doing its job.

53A customer receives a large payment described as a loan from an individual. How do you treat it?

Loans between individuals are common and legitimate, so I'd assess rather than assume, but "loan" is also a standard explanation for unexplained funds because it's easy to assert.

What I'd want is evidence the loan is real: a written agreement, terms including interest and repayment schedule, and evidence the lender had the funds to lend.

That last point matters most. A loan explanation just moves the source-of-funds question to the lender, and if they couldn't plausibly have that money, the explanation collapses.

I'd also look at whether repayments actually occur. A loan with no repayment activity over time isn't functioning as a loan.

The relationship matters too — family lending is normal; a substantial loan from someone with no evident connection is less so.

Where the agreement exists, the lender is identifiable and repayments follow, I'd document and close. Where "loan" is asserted with nothing supporting it, I'd treat it as unexplained and escalate.

54A property purchase is funded from multiple unrelated sources. What is your read?

Property is attractive for integration because it absorbs large sums in one transaction, so funding structure matters.

Multiple sources aren't inherently suspicious. A purchase might legitimately combine savings, a mortgage, proceeds from selling another property, a family gift, and an inheritance. That's ordinary.

What I'd assess is whether each component is identifiable and explicable. Family gifts should come from identifiable relatives, mortgage funds from a lender, sale proceeds from a solicitor's client account.

The concerning version is funds arriving from multiple parties with no relationship to the buyer, particularly in round amounts or from jurisdictions unconnected to them. That pattern suggests pooling of third-party money rather than the buyer's own resources.

I'd also check timing — contributions arriving shortly before completion from unconnected senders is more concerning than long-held savings.

Where components are evidenced, I'd document each. Where several can't be explained, I'd escalate, because the aggregate matters even if individual amounts seem modest.

55A customer's account is used to pay what appear to be personal expenses from a business account, at scale. Concern?

This is common enough that I'd be careful about over-reading it. Owner-managed businesses frequently blur personal and business spending, and while that's a tax and accounting issue, it isn't automatically money laundering.

What I'd assess is scale and pattern. Occasional personal spending on a business card is unremarkable; a business account funding an entire lifestyle at a level the business couldn't support is different.

The key question is whether the business genuinely generates what's being spent. If declared turnover is modest but the account funds substantial personal expenditure, the source of those funds is the real issue.

I'd also look at whether the business shows normal operating costs. A company with heavy personal spending and no evident trading expenses may not be trading at all.

Where the business is genuinely profitable and the spending is proportionate, I'd note it as a governance matter rather than escalate. Where spending exceeds any plausible business income, I'd escalate on source of funds.

56An alert involves a payment to a company later found to be under investigation for fraud. What do you do?

The counterparty's status is relevant intelligence but doesn't determine our customer's position, so I'd assess rather than assume contamination.

First I'd establish the facts: is it definitely the same entity, what is the investigation about, at what stage, and how credible is the source. An open investigation is not a finding.

Then I'd look at our customer's relationship with them — how long, how many transactions, what the commercial basis is, and whether it's consistent with the customer's business.

Many legitimate businesses transact with a company that later turns out to be fraudulent. Being a supplier or customer of a fraudster isn't itself wrongdoing.

What would concern me is a pattern suggesting knowledge or participation — payments with no evident commercial purpose, unusual terms, or activity aligning with the alleged fraud.

I'd document the finding on the customer's file, reassess the risk rating, review historic activity, and escalate if the relationship looks like more than ordinary commerce.

57A customer receives large fiat credits from a crypto exchange with no declared crypto activity. How do you approach it?

The undeclared element is what interests me more than the crypto itself. Crypto trading is legal and increasingly common, so receiving funds from an exchange isn't inherently suspicious.

But if the customer never declared crypto activity, our profile is wrong, and that's a starting point for the conversation rather than an accusation.

I'd ask about their trading — how long, what scale, which platforms, and where the funds originally came from to buy the assets. That last question matters most, because crypto proceeds ultimately trace back to fiat that came from somewhere.

I'd also assess whether the exchange is regulated in a recognised jurisdiction, since a licensed exchange applies its own KYC and monitoring, which provides some comfort.

Concerns would be an unregulated or offshore exchange, amounts far exceeding what the customer could have invested, or reluctance to explain the original funding.

If it's explained and evidenced, I'd update the profile and expected activity. If not, I'd escalate.

58Blockchain analytics shows the customer's wallet has indirect exposure to a darknet marketplace. What does that mean?

I'd be careful about how I interpret "indirect," because it's often misunderstood and over-weighted.

Direct exposure — funds received straight from a darknet address — is a serious finding. Indirect exposure means funds passed through intermediaries at some remove, and given how crypto circulates, distant indirect exposure is extremely common and can affect entirely innocent users.

So the questions are how many hops away, what proportion of the customer's funds are affected, and how recent the exposure is. One hop with a large proportion is very different from five hops with a trace amount.

I'd also check whether the exposure is one-off or repeated, since repetition suggests a relationship rather than coincidence.

I'd look at the customer's overall pattern — do they use mixers, unregulated exchanges, or privacy coins, which would corroborate concern.

Close, substantial or repeated exposure I'd escalate. Distant trace exposure with no other indicators I'd document and monitor rather than treat as evidence of criminality.

59A customer converts fiat to crypto and back repeatedly with no apparent gain. Read?

Round-tripping with no economic purpose is a layering indicator, because the conversions accomplish nothing commercially while breaking the trail.

I'd first check whether there genuinely is no gain. Active traders convert frequently, and short-term trading can look circular while pursuing small margins. Trading records would show that.

What concerns me is conversion in and straight back out with no holding period and no market exposure — that's not trading, since no position is taken.

I'd look at whether different platforms are used on each leg, whether the crypto touches other wallets between conversions, and whether the fiat returns to the same account or a different one.

Funds leaving as fiat, converting to crypto, moving through wallets, and returning as fiat to a different account is a classic layering chain.

Legitimate explanations include arbitrage between exchanges and payment settlement in crypto. Both are evidenceable.

Absent that, I'd escalate on the basis that the activity has no economic purpose.

60A customer sends crypto to a wallet flagged as belonging to a mixing service. What do you do?

Mixer use is a strong indicator, because the sole function of a mixer is to obscure the transaction trail. Unlike many crypto services, there isn't a mainstream legitimate use case that requires it.

Privacy is the argument customers make, and I'd acknowledge it's not universally illegal — some people use mixers for genuine privacy reasons rather than criminality.

But in a regulated context it defeats the traceability our controls depend on, and several mixing services have been sanctioned outright, which adds a sanctions dimension.

So my first check would be whether the specific service is designated, because that changes this from an AML question into a sanctions one requiring immediate escalation.

Otherwise I'd look at scale, frequency, and what the funds did before and after — mixer use following receipts from unexplained sources is much more concerning than a single small transfer.

Given the deliberate nature of using a mixer, I'd escalate rather than seek an explanation first.

61A crypto-related payment arrives with incomplete Travel Rule information. Significant?

Yes, and it's worth treating as a control issue as well as a case issue.

The Travel Rule requires originator and beneficiary information to accompany transfers above a threshold, mirroring the wire transfer rule. Missing or incomplete data means the transfer arrived without the identifying information it should carry.

Incomplete data can be technical — implementation across VASPs is uneven and interoperability is imperfect. So I wouldn't assume evasion immediately.

But it can also indicate a sending institution with weak controls, or deliberate omission.

I'd check whether the sending VASP is regulated, whether this is a recurring pattern from that counterparty, and whether the missing fields are consistently the same ones — consistent omission of the originator name reads differently from occasional truncation.

On the payment itself, missing originator information means I can't assess counterparty risk, which is a reason to hold or escalate rather than process.

Recurring gaps from one VASP I'd raise as a counterparty risk issue.

62A customer's crypto activity involves privacy coins exclusively. How do you assess it?

Exclusive use of privacy coins is a meaningful signal, because it removes traceability by design — blockchain analytics can't follow them the way it can transparent chains.

There's a legitimate privacy argument, and some users hold privacy coins for principled reasons. I wouldn't treat holding them as evidence of criminality.

But exclusivity matters. A customer whose entire activity avoids traceable assets is different from one holding a mixed portfolio.

Practically, many regulated firms restrict or prohibit exposure entirely, so my first check is our own policy — if it's prohibited, this is a policy breach requiring escalation regardless of the customer's explanation.

Where permitted, I'd focus on what I can see: the fiat legs, the amounts, whether they're consistent with declared income, and the counterparty platforms.

I'd also consider whether the pattern combines with other indicators — unregulated exchanges, mixer use, or unexplained source of funds. That combination is what would drive escalation.

63A customer receives instant payments from many senders and forwards them within minutes. What is the challenge here?

The pattern is a classic mule shape — collection and rapid forwarding — but instant payments change the practical problem significantly.

With traditional transfers there's usually a settlement window allowing intervention. Instant payments settle irrevocably in seconds, so by the time a post-event alert generates, the money has gone and can't be recovered.

That means detection alone doesn't protect anyone, and the response has to be about stopping future activity rather than recovering past funds.

So I'd escalate quickly and consider whether account restrictions are warranted while the investigation continues, since the alternative is watching further funds pass through.

I'd map the senders and beneficiaries, because the network is where the value lies — the same beneficiaries likely appear across other accounts.

I'd also flag that this pattern argues for real-time or near-real-time controls rather than overnight batch detection, which is a control design point worth raising beyond the individual case.

64A customer uses a payment app to receive many small amounts from strangers. How do you approach it?

I'd start with what the account is for, since payment apps are used legitimately for a wide range of small-value receipts.

Innocent explanations are common: someone selling items online, a freelancer taking small payments, splitting bills, or running a small side business. Marketplace sellers in particular receive from many strangers routinely.

What I'd assess is whether volume and pattern fit that. Occasional varied amounts consistent with selling items reads very differently from steady round-sum receipts from an ever-changing set of senders.

Then what happens next. Funds accumulating and being spent normally suggests genuine income; funds arriving and being immediately forwarded or withdrawn as cash suggests collection.

I'd also consider the customer profile — a student or someone with no declared business receiving substantial aggregate amounts is more concerning than a registered sole trader.

Where it fits a plausible activity, I'd document and close. Where the pattern is receive-and-forward with no explanation, I'd escalate as possible mule activity.

65A customer's declared crypto holdings far exceed what their income could have funded. What now?

The gap is the issue, and it's the same source-of-wealth question that applies to any asset class.

I'd first consider legitimate explanations specific to crypto. Early investment is the big one — someone who bought small amounts years ago may hold assets worth far more than they ever invested, and appreciation can be dramatic. That's entirely legitimate and evidenceable through transaction history.

Other explanations include mining, receiving crypto as payment, airdrops, or gifts.

So I'd ask how the holdings were acquired and seek evidence — exchange records showing purchase history and dates, wallet history, or mining records.

The concerning version is holdings that appeared without a corresponding purchase trail, or a customer who can't explain how they acquired them.

I'd also check the original fiat funding, since even appreciated holdings started somewhere.

Where acquisition is evidenced, appreciation explains the gap. Where it isn't, unexplained wealth is unexplained regardless of the asset type.

66An exchange the customer uses is not regulated in any jurisdiction. Does that change your assessment?

Yes, materially, because a regulated exchange applies its own KYC, screening and monitoring, and that gives some assurance about who is on the other side. An unregulated one provides none of that.

It means funds arriving from that platform have effectively bypassed any controls, and I have no basis to assume the counterparty was identified or screened.

I'd check the platform's status properly — whether it's registered anywhere, whether it's on any regulator warning list, and whether it has been subject to enforcement.

Warning lists matter particularly, since several jurisdictions publish lists of platforms operating without authorisation.

I'd also consider why the customer uses it. Some unregulated platforms offer services regulated ones don't — higher limits, no verification, or privacy features. That choice is informative.

Where the platform is unregulated and the customer has regulated alternatives available, I'd weight that significantly, and I'd escalate if combined with unexplained volumes or source of funds gaps.

67You have reasonable suspicion but no proof. Do you escalate?

Yes, and I'd be clear that proof isn't the standard.

The test is reasonable suspicion — a reasonable basis to suspect the activity may involve criminal property or purposes. Waiting for proof would mean almost nothing ever gets reported, because institutions rarely have evidence in an evidential sense.

What I'd need is articulable grounds: the specific facts, the pattern, why the innocent explanation doesn't hold, and what I could and couldn't verify.

That's the difference between reasonable suspicion and a hunch. If I can explain why a reasonable person reviewing the same facts would suspect, that meets the threshold.

I'd escalate with that reasoning set out, and be explicit about the limits of what I know rather than overstating.

I'd also avoid the opposite error — escalating on generic unease to be safe. Defensive reporting degrades the value of the regime and regulators have criticised it. The obligation is to assess properly, then report where suspicion genuinely exists.

68Your manager tells you to close a case you believe should be escalated. What do you do?

First I'd make sure I've made my case properly, because disagreement sometimes reflects my not having explained the reasoning clearly.

So I'd set out in writing the specific evidence, the pattern, why the innocent explanation doesn't hold, and what remains unexplained. Written analysis is harder to dismiss than a verbal concern and it forces me to be precise.

If my manager still disagrees after seeing that, I'd accept the decision — they may have context I lack, and reasonable people weigh evidence differently.

But I'd ensure my assessment stays documented in the case record rather than existing only in a conversation. That protects the firm's record and me.

Where I'd go further is if I believed a genuine reporting obligation was being missed. In many jurisdictions individuals carry personal exposure for failing to report, so I'd use the escalation route — direct to the MLRO where the process allows, or whistleblowing procedures if necessary.

That's not for ordinary disagreement, but suppression of suspicion is exactly what those routes exist for.

69You need more information from the customer, but contacting them might tip them off. How do you proceed?

I'd take guidance before making any contact, because this is precisely the situation where an analyst acting independently causes real damage.

The tension is genuine. Ordinary due diligence enquiries are legitimate and happen constantly, and refusing ever to contact a customer would paralyse the work. But once suspicion exists, an enquiry can alert the subject and prejudice an investigation, and tipping off is a criminal offence.

So the question is whether my enquiry would be routine or would signal that something specific is being examined.

I'd escalate to the MLRO with the position: what I know, what I need, and why I think contact is risky. That decision sits with them, not me.

Meanwhile I'd exhaust what I can obtain without contact — internal records, public sources, corporate registries, prior files.

Often that resolves it, and the enquiry becomes unnecessary. Where contact is authorised, I'd stick to approved wording precisely.

70A customer asks directly whether a report has been made about them. What do you say?

I'd say nothing that confirms or denies it, and I'd stick to the firm's approved wording.

This is the sharpest tipping-off risk, because even a denial carries information — if I deny it in cases where no report exists and go silent where one does, the pattern itself discloses.

So the answer has to be consistent regardless of the facts: something along the lines of not being able to discuss internal processes, and that checks apply to activity from time to time.

Tone matters as much as words. Becoming defensive or evasive signals something, so a calm routine response is better.

I'd also not improvise reassurance — telling someone there's nothing to worry about is both potentially untrue and potentially disclosive.

I'd record the question precisely and escalate it. A customer asking directly is significant information in itself: it suggests they anticipate being reported, and the MLRO should know that.

71You escalate a case and it is not reported. Later the customer is arrested. How do you view that?

I'd want to understand what happened, but I wouldn't assume the earlier decision was wrong just because of the outcome.

Decisions have to be judged on the information available at the time. A reasonable assessment can turn out to be incorrect without having been unreasonable — and hindsight makes everything look obvious.

What I'd examine is whether the decision was properly reasoned on what was known. If the MLRO considered the evidence and concluded suspicion wasn't reached, that's a legitimate judgement even if events proved otherwise.

Where it would concern me is if the escalation wasn't properly considered, if my reasoning was never engaged with, or if the closure was driven by workload or commercial pressure.

Either way there's a learning question: was there an indicator we should have weighted more heavily, and would our scenarios catch this pattern next time?

I'd raise it as a case review rather than as blame. Firms that treat these as learning opportunities improve; those that treat them as failures encourage defensive reporting.

72You are drafting an escalation. What makes it useful rather than just complete?

The reasoning. A complete escalation lists what happened; a useful one explains why it's suspicious in a way the reader can follow without repeating my work.

So I'd structure it around the analysis rather than the chronology. What the customer's expected profile is, what actually happened, why that's inconsistent, what explanation was offered or sought, what I verified and what I couldn't, and what remains unexplained.

Transaction detail supports that rather than replacing it. A list of forty transactions with no interpretation forces the MLRO to redo the investigation.

I'd be specific about amounts, dates, counterparties and jurisdictions, since those are the details investigators actually use.

I'd also state clearly what I ruled out and why, because that's what distinguishes an assessed case from a forwarded alert.

And I'd avoid overstating — saying the activity is unexplained is accurate; asserting the customer is laundering money is a conclusion I'm not in a position to reach.

73The customer relationship continues after a report is filed. How does that affect your work?

It means continuing to monitor and service the relationship as normally as possible, which is genuinely uncomfortable but usually correct.

Exit isn't automatic after a report. Authorities sometimes prefer relationships to continue so activity can be observed, and abrupt exit can prejudice an investigation or amount to tipping off.

Practically, I'd continue monitoring with heightened attention, and file continuing activity reports where the suspicious pattern persists, on whatever cycle applies.

I'd be careful about anything that could disclose — no unusual questions, no changes in service that would seem inexplicable to the customer, and no discussion outside those who need to know.

Handling customer contact naturally while knowing a report exists is one of the harder parts of the role.

I'd also make sure the file records the ongoing position clearly, so anyone picking it up understands the context without needing to ask.

74Two analysts reach opposite conclusions on identical facts. What does that tell you?

That the criteria aren't clear enough, rather than that one analyst is wrong. Genuine borderline cases exist, but consistent divergence on the same facts points to a standards problem.

I'd want to understand where the reasoning diverged — different weight on the same indicator, different assumptions about what's normal for that customer type, or different thresholds for what counts as sufficient explanation.

Usually it's the last one: one analyst accepts an unverified explanation, the other doesn't.

The fix is calibration — worked examples, documented criteria on what evidence is required, and sessions where analysts assess the same case and compare reasoning.

I'd also flag it as a quality issue, because if two analysts differ on identical facts, outcomes across the whole population are inconsistent, and that's what audit will find.

On the specific case, I'd escalate it for a decision rather than have the two of us resolve it informally, since the disagreement itself is useful information for whoever sets the standard.

75You realise a case you escalated last month contained a factual error. What do you do?

Correct it immediately and inform whoever holds the case, because a report or escalation containing wrong facts is worse than none — decisions may have been taken on it, and in some jurisdictions the report has already gone to the FIU.

I'd be precise about what was wrong: a misread amount, a wrong date, a counterparty misidentified, or a mistaken inference. The materiality determines the response.

If it changes the assessment substantively — for example the transaction was smaller than stated, or the counterparty was actually a known related party — that needs flagging urgently.

If it's immaterial, it still needs correcting for the record.

Where a report has been filed, the MLRO will decide whether a correction to the FIU is required, which isn't my call.

I'd also look at how the error arose. If I misread a field or misunderstood a data source, others may be doing the same, and that's worth raising beyond my own case.

76A colleague asks you to look at a case informally before they escalate it. Any issue?

No issue at all, and I'd encourage it — a second perspective on a borderline case improves decisions and is exactly how consistency develops in practice.

What I'd be careful about is that the discussion supplements rather than replaces the formal process. Informal input shouldn't become a way of resolving cases outside the record.

So I'd give my view honestly, including if I disagreed, and encourage them to document their own reasoning and escalate through the proper route.

I'd also be conscious of confidentiality — discussing a case with a colleague in the same function on a need-to-know basis is fine; discussing it more broadly is not.

If the case involved suspicion, I'd be careful that the conversation stays within the team.

And if I thought they were seeking reassurance to justify closing something they were uneasy about, I'd say so directly. Being asked to endorse a weak closure is different from being asked for a view.

77You suspect an internal colleague may be involved in facilitating suspicious activity. What do you do?

This needs a different route from an ordinary escalation, and I'd be careful not to handle it through the normal channel.

Internal cases have their own procedures — usually internal fraud, security, or a whistleblowing route — precisely because the standard path may involve the person concerned or their colleagues.

So I'd not discuss it with the team, not raise it with my immediate manager if there's any possibility of connection, and not investigate it myself.

I'd document what I observed factually — specific actions, dates, cases — rather than characterising motive, and take it to the appropriate function.

I'd also avoid accessing records beyond what my role requires, since doing my own investigation could itself be a policy breach and could compromise a formal one.

Confidentiality is critical here, both to protect the investigation and because the suspicion may be wrong. Getting this wrong publicly would be seriously unfair to a colleague.

78Law enforcement contacts you directly asking about a customer. How do you respond?

I wouldn't respond substantively myself. I'd take the details and route it through the proper channel — usually the MLRO, legal, or a dedicated law enforcement liaison function.

There are good reasons. The request needs its legal basis verified, the authenticity of the requester confirmed, and the scope of what can lawfully be disclosed assessed. Providing customer information without proper basis breaches confidentiality and data protection.

Impersonation of law enforcement is also a known technique for obtaining customer information.

So I'd be courteous, take contact details, explain that requests are handled through a specific channel, and pass it on promptly rather than obstructing.

I'd also not tell the customer about the contact, since that could prejudice an investigation and may amount to tipping off.

And I'd document that the contact occurred, which is itself relevant information for the customer's file even if no disclosure follows.

79You are told the escalation rate on your team is far higher than peers. How do you interpret that?

It's worth investigating rather than taking as criticism or as evidence of diligence, because either interpretation could be right.

A high rate might mean the team is escalating defensively — passing borderline cases up rather than doing the analysis. That degrades the MLRO's ability to focus and floods the process.

Equally it might mean the team's scenarios are poorly tuned so they receive more genuinely suspicious alerts, or that they handle a higher-risk portfolio.

It could also mean other teams are closing cases they shouldn't, and we're the accurate ones.

So I'd look at outcomes rather than volume — what proportion of our escalations result in reports, compared with peers. A high escalation rate with a high conversion rate suggests good detection; a high rate with low conversion suggests we're passing decisions upward.

I'd also compare portfolio risk profiles before drawing conclusions, since comparing teams with different customer bases isn't meaningful.

80You are asked to reduce the number of cases you escalate. How do you respond?

I'd want to understand what's actually being asked, because there are two very different versions.

If the concern is that I'm escalating without doing the analysis — passing cases up that I should be resolving — that's legitimate feedback and I'd act on it. Defensive escalation is a real problem, and improving my own assessment would be the right response.

If the ask is to escalate fewer genuinely suspicious cases to reduce workload or reporting volumes, that's different and I wouldn't comply. The threshold is reasonable suspicion, and it isn't adjustable to manage capacity.

So I'd ask directly which it is, and propose reviewing a sample of my escalations to see whether they were justified. That turns an instruction into an evidence-based conversation.

If the analysis showed my escalations were sound and the request persisted, I'd escalate the request itself to compliance leadership and document it.

Being told to report less is a serious matter, and it's precisely the pattern enforcement actions describe.

81You discover a monitoring scenario has generated no alerts for six months due to a data feed failure. What do you do?

This is a serious control failure and I'd treat it with more urgency than any individual case.

First, containment: confirm the scope — which scenario, which data, from when — and get the feed fixed. Until it's working, the gap continues.

Then assess exposure. Six months of transactions passed through unmonitored against that scenario, so I'd want to know what population that covers and what risk the scenario was designed to detect.

A retrospective review over the affected period is the standard response — running the scenario against historical data to identify what would have alerted.

I'd escalate to compliance leadership immediately rather than treating it as an IT ticket. Silent detection failures are among the most common findings in enforcement actions precisely because nobody notices — there are no alerts to be missing.

I'd also ask why it wasn't detected sooner. The absence of alerts should itself have been monitored, and that's the deeper control gap worth raising.

82Alert volumes triple overnight after a tuning change. What is your response?

I wouldn't revert it unilaterally or let alerts age unreviewed while it's debated, since both create risk.

First I'd protect coverage: triage by risk so the highest-risk alerts are worked while the volume issue is resolved. Letting everything age equally means high-risk cases sit unreviewed alongside noise.

Then analyse what's driving it. Are the new alerts genuinely detecting something previously missed, or is the change generating noise on a customer segment where the threshold no longer fits? Sampling a batch answers that quickly.

That distinction determines the response. If detection genuinely improved, the answer is resourcing, not reverting. If it's miscalibration, the change needs adjusting through proper governance.

I'd take that analysis back through the change process with evidence rather than an impression.

Meanwhile I'd report the backlog position transparently. A reported backlog with a plan is manageable; a hidden one that emerges in audit is not.

83You notice a customer type that never generates alerts despite obvious risk. What does that suggest?

A detection gap, and it's the kind that only surfaces if someone thinks about what isn't happening rather than what is.

Alerts tell you what the system found. Silence tells you either there's nothing to find, or nothing is looking — and those look identical from the outside.

So I'd check whether scenarios actually cover that customer type's risk. Thresholds calibrated for retail customers may never trigger on a business with high legitimate turnover, meaning genuinely unusual activity sits below the line.

I'd also verify the data. Sometimes a segment isn't alerting because its transactions aren't feeding the system properly, which is the same silent failure as a broken feed.

Then I'd sample manually — reviewing a set of those customers' activity directly to see whether anything should have alerted.

Manual sampling is the only way to test coverage, because the system can't report on what it isn't monitoring.

I'd raise it as a coverage gap with the sampling evidence rather than as an impression.

84Below-the-line testing shows several transactions just under threshold that look suspicious. What does that mean?

It means the threshold is set too high, and that's exactly what below-the-line testing exists to reveal.

The finding is significant because those transactions were never reviewed by anyone — they didn't alert, so no analyst ever saw them. Unlike a false positive, which costs time, this is undetected risk.

I'd quantify it: how many transactions, how far below threshold, and how many look genuinely suspicious rather than merely close to the line.

Then investigate the ones that look suspicious as cases in their own right, since they may warrant escalation independently of the tuning question.

On the threshold, I'd take the evidence through change governance with a proposal — usually lowering it, possibly with better segmentation so the reduction doesn't flood the team.

I'd also check whether the threshold was ever justified with data or simply inherited, since unjustified thresholds are a common regulatory finding.

85You inherit a queue with 4,000 aged alerts. What are your first actions?

Three things, in order.

First, triage by risk rather than working chronologically. Chronological processing means high-risk alerts from last week sit behind low-risk ones from six months ago. I'd segment by customer risk rating, value, sanctions adjacency and prior escalations, and work the highest exposure first.

Second, establish the cause, because the fix differs entirely. If it's tuning generating excessive noise, more analysts won't solve it. If it's capacity, tuning changes won't. If it's a data issue creating spurious alerts, neither will.

Third, report the position honestly to senior management with a remediation plan and realistic timeline.

That third point matters most. Backlogs become regulatory findings not because they exist but because they were concealed or left unaddressed.

I'd also make sure the ageing position is tracked from now on, so it doesn't rebuild once the immediate backlog clears.

86A scenario produces almost entirely false positives. Should it be switched off?

Not without analysis, and definitely not informally.

First I'd understand why. A high false positive rate often reflects poor customer segmentation rather than a bad scenario — the logic may be sound but applied to a population it doesn't fit. Fixing segmentation can transform performance without losing the detection.

I'd also check whether it has ever produced escalations. A scenario with a low hit rate that occasionally catches something significant may still be worth running, particularly if it covers a risk nothing else detects.

That's the key question: what risk does it address, and is anything else covering it? Switching off the only detection for a typology creates a coverage gap even if the scenario performs poorly.

If it genuinely addresses no live risk and duplicates other coverage, retiring it is legitimate — but through documented change governance with rationale, not by an analyst quietly suppressing it.

Undocumented scenario changes are a serious governance finding.

87You find transaction data feeding the monitoring system is missing counterparty details. Significance?

Substantial, because counterparty information is central to most meaningful detection — who money moves to and from is often more informative than the amount.

Without it, scenarios relying on counterparty analysis can't function properly. Network detection, repeated beneficiary logic, and jurisdiction-based rules all degrade or fail silently.

I'd establish the scope: which transaction types, which channels, how long, and what proportion of records are affected. Missing details on a small subset is different from a systemic gap.

Then which scenarios depend on that field, since that determines what detection is compromised.

I'd escalate it as a data quality control issue rather than working around it case by case. Analysts compensating manually is not a control — it's a workaround that hides the problem.

I'd also note that it affects investigations too, not just alerting: I can't assess counterparty risk on data I don't have, which weakens every case in the affected population.

88Quality assurance finds 30 percent of your team's closures lack adequate documentation. How do you respond?

I'd accept it and treat it as systemic rather than as thirty percent of individuals being careless, because a failure rate that high points to a cause beyond individual performance.

I'd want to know what's driving it. Is the documentation standard clearly defined and understood? Are analysts under time pressure that makes proper write-ups impractical? Was training adequate? Is the case management system making good documentation difficult?

Time pressure is the most common cause — analysts asked to close volumes that don't allow proper recording.

Then remediate the affected population. Files closed without adequate documentation may need reviewing, since we can't demonstrate the decisions were sound.

On prevention, I'd clarify the standard with worked examples, adjust expectations if volume is the cause, and build documentation quality into ongoing QA rather than periodic sampling.

Retraining alone rarely fixes a rate that high, and I'd say so rather than proposing it as the whole answer.

89A new product launches and you realise monitoring coverage was never built for it. What now?

I'd escalate immediately, because the product is live and unmonitored, which is an active exposure rather than a planning gap.

First I'd establish what's actually happening — is there no coverage at all, or partial coverage through generic scenarios that weren't designed for it? Partial coverage is better than none but may miss the product-specific risks.

Then I'd look at what risks the product presents: how it could be abused, what typologies apply, and whether existing scenarios catch any of them.

I'd also check whether the necessary transaction data is even being captured, since scenarios can't be built on data that doesn't flow.

In the short term, compensating controls may be needed — manual review of activity on that product, or restrictions until coverage exists.

Longer term this is a governance question: new products should go through risk assessment and monitoring design before launch. That it didn't is the finding worth raising, because it will recur otherwise.

90An audit finding from last year was marked remediated but the underlying issue persists. What do you do?

I'd raise it promptly, because a falsely closed finding is worse than an open one — the firm believes a risk is addressed when it isn't, and regulators treat known-and-unremediated issues as a serious aggravating factor.

First I'd verify carefully that the issue genuinely persists and that I'm not misreading the scope of what was remediated. Sometimes a finding is closed against a narrower definition than expected.

If it does persist, I'd document the evidence specifically — what the finding required, what was implemented, and what remains unaddressed.

Then escalate through compliance and, where appropriate, to audit directly, since they need to know their finding was closed incorrectly.

I'd frame it factually rather than as an accusation. Findings sometimes get closed on a plan rather than on evidence of effectiveness, which is a process weakness rather than misconduct.

The wider point is worth raising too: if remediation is being signed off without effectiveness testing, other findings may be in the same position.

91A senior executive asks you to close an investigation into a major client. How do you handle it?

I'd complete the investigation on its merits and document the request.

The client's commercial importance has no bearing on whether the activity is suspicious, and closing a case because of who the customer is would be exactly the failure enforcement actions describe.

I'd respond professionally rather than confrontationally — explaining that I'll complete the review properly and that if the activity is explained, it will close on that basis.

What I would do is escalate the approach itself to the MLRO or compliance leadership. An executive asking an analyst to close a case is a compliance concern independent of the case outcome, and it needs to be visible.

I'd document what was said, by whom and when, factually.

If they have a genuine view on the case, the right route is providing information or raising it through governance — not instructing the analyst. I'd make that distinction clear.

92A relationship manager offers to explain a customer's activity informally rather than through the case process. Any concern?

No concern about the conversation itself — RM knowledge is genuinely valuable and often resolves cases quickly. They know the customer's business and can explain patterns that look odd from transaction data alone.

What matters is that the information enters the record. An explanation that only exists in a conversation isn't evidence, and a file closed on it would fail review.

So I'd take the input, then document it: what was explained, by whom, and what supporting evidence exists. Where the explanation is material, I'd ask for documentation rather than relying on the account.

I'd also be alert to the difference between explaining and advocating. An RM providing context is helpful; an RM pressing me toward a conclusion is something else.

And I'd be conscious that RMs sometimes have information the customer gave them that hasn't been verified. Second-hand assurance isn't verification, and I'd treat it as a lead rather than an answer.

93You are under pressure to hit closure targets and quality is slipping. What do you do?

I'd raise it rather than absorb it, because quietly lowering standards to hit numbers is how firms end up in remediation.

First I'd be honest with myself about whether it's genuinely a volume problem or an efficiency one. There's often real scope to work faster — better prioritisation, less duplication, clearer templates — without reducing depth. I'd exhaust that first so the conversation isn't just about resource.

Then I'd raise the gap with specifics: current volumes, realistic throughput at the required standard, and the shortfall. Evidence is more persuasive than a general complaint.

I'd propose options — risk-based triage so low-risk alerts move faster, temporary resource, or accepting a transparent backlog rather than a hidden quality problem.

The key argument is that rushed closures don't reduce work, they defer it. A file closed inadequately becomes a remediation case later at far greater cost.

If pressure continued regardless, I'd document the position and escalate.

94You recognise a customer under investigation as a friend's employer. What do you do?

Declare it and step away from the case.

The connection is indirect, so it might seem overcautious. But I have a personal interest in the outcome — the investigation could affect my friend's employment — and that's enough to compromise the decision's reliability even if I'd be objective.

There's also a confidentiality risk. Knowing something about my friend's employer that I can't disclose puts me in a difficult position, and any accidental indication would be a serious breach.

So I'd tell my supervisor, explain the connection, and have the case reassigned, with the reason documented.

I'd say nothing to my friend, including anything oblique. Even a general comment could constitute disclosure.

I'd rather declare a connection that turns out not to matter than have it emerge later, when every decision I made would be questioned regardless of its merits.

95You suspect your own firm's product design is being systematically exploited. How do you raise it?

Through the proper channel with evidence, because this is a systemic finding rather than a case, and it needs to reach people who can change the product.

I'd gather the evidence first — how many cases show the pattern, what feature is being exploited, and how. A single case is an anecdote; a documented pattern across multiple customers is a finding.

I'd articulate specifically what design feature enables it: a limit, a verification gap, a speed of settlement, or an anonymity feature.

Then escalate to compliance leadership, and expect it to reach product and risk governance, since the fix isn't within the AML function.

I'd frame it constructively rather than as criticism. Products are designed for legitimate use and exploitation often isn't foreseeable — the useful contribution is identifying it early.

I'd also propose interim mitigations, since product changes take time and the exploitation continues meanwhile.

96You are asked to sign off on a case you did not investigate. What is your position?

I wouldn't sign it. Approval means I've assessed the work and agree with the conclusion, and signing off on something I haven't reviewed is a false record.

It also creates personal exposure. If the case is later found deficient, my name is on it regardless of who did the work.

If the intent is that I review and approve, that's fine — but then I need to actually review it, which takes time and access to the underlying material.

So I'd ask which is being requested. Usually it's a workflow issue where someone is unavailable, and the honest answer is that approval requires review.

If the pressure is simply to clear a queue, I'd decline and explain why. Rubber-stamping approvals defeats the purpose of having an approval step at all.

And if it were routine practice on the team, I'd raise that separately, because it would mean the second review control isn't functioning.

97A customer's activity is suspicious but they are a vulnerable person who may be a victim. How does that change your approach?

It changes how the relationship is handled, but not the reporting obligation.

If someone is being coerced or exploited — a mule recruited under pressure, an elderly customer being financially abused, or a trafficking victim — the activity is still reportable, and reporting may be what brings help.

What changes is everything around it. I'd flag the vulnerability clearly in the escalation, since the MLRO and any authorities receiving the report should know the person may be a victim rather than an organiser.

I'd be especially careful about customer contact. Questioning someone under coercion can put them at risk from whoever is controlling them, so I wouldn't make enquiries without guidance.

I'd also consider whether the firm's vulnerable customer procedures apply alongside the AML process, since there may be safeguarding obligations.

The instinct to protect them by not reporting is understandable but wrong — reporting is often how these situations are identified and addressed.

98You have escalated the same concern three times and nothing has happened. What do you do?

I'd escalate differently rather than repeating the same route, since three attempts suggests the message isn't landing or isn't being acted on.

First I'd check whether something did happen that I'm not aware of. Reporting outcomes aren't usually communicated back, so a case may have been reported without my knowing. I'd confirm before assuming inaction.

If genuinely nothing has happened, I'd consolidate the concerns into a single documented submission showing the pattern across all three, rather than a fourth individual escalation. The repetition itself is evidence.

Then take it to a different level — the MLRO directly if I've been going through a manager, or compliance leadership.

If it still went nowhere and I believed a reporting obligation was being missed, whistleblowing routes exist for exactly this. That's a significant step and I wouldn't take it lightly, but repeated suppression of escalations is what those routes are for.

Throughout, I'd keep my own record of what I raised and when.

99You realise you have been applying a scenario incorrectly for months. What do you do?

Report it immediately, and treat the affected population as the priority rather than my own position.

I'd establish the scope: what I misunderstood, how many cases were affected, and in which direction the error ran. Closing cases that should have escalated is more serious than the reverse, though both need correcting.

Then raise it with my supervisor with that assessment rather than a vague admission, since they need to know the exposure to decide on remediation.

I'd also consider whether others have the same misunderstanding. If the scenario logic or guidance was unclear enough that I got it wrong for months, colleagues may be doing the same — and that's a much bigger issue than my cases.

Self-reporting is treated far better than discovery through QA or audit, and concealing it would turn a training issue into an integrity one.

The constructive outcome is usually clearer guidance and a remediation review, not blame.

100What would make you refuse to continue working a case?

A few situations, and I'd distinguish between refusing and escalating.

A conflict of interest — if I know the customer personally or have any stake in the outcome, I'd decline and hand it over. That's not refusal so much as proper conflict management.

If I were instructed to reach a predetermined conclusion, I'd decline. Being told what to find isn't investigation, and complying would put my name on a false assessment.

If I were asked to act outside my authority — approving something requiring senior sign-off, or releasing a payment with an unresolved sanctions match — I'd decline and escalate.

And if I believed continuing would prejudice something more serious, such as an internal matter requiring a different route, I'd stop and refer it.

What wouldn't make me refuse is difficulty, workload or disagreement with a decision. Those are things to raise and work through, not reasons to step back.