1Walk me through your AML experience.

Cover four things in about ninety seconds: the products and customer types you monitored, the alert types and rough volumes you handled, what you owned versus what you escalated, and any specialism you developed.

The ownership point is what separates candidates. "I investigated alerts" says little; "I owned end-to-end investigation including drafting escalations to the MLRO, and contributed outcome data to quarterly tuning reviews" tells them your level immediately.

Finish by connecting it to the role you are applying for — what you have done that maps onto what they need.

2Describe the most complex investigation you have run.

Choose a case with genuine analytical difficulty rather than one that was simply large. Good candidates: a network across multiple accounts, trade-based laundering, or a case where the explanation was superficially plausible and you had to work out why it did not hold.

Structure it as: what triggered it, what the customer's expected profile was, what you found, what you initially thought and what changed your view, what you could not verify, and the outcome.

The detail that impresses is the point where the evidence shifted your assessment. That demonstrates investigation rather than confirmation.

Be ready for follow-ups on why you did not do X — interviewers probe this answer hardest.

3What alert volumes and case types have you handled?

Give daily or weekly throughput, but pair it with your escalation rate and SAR conversion rate if you have them. Someone who knows their own conversion rate is demonstrably thinking about effectiveness, not just output.

Break down the case mix — cash-based, wire, trade, crypto, correspondent — because that tells them how transferable your experience is.

If your volumes were low because cases were complex, say so and explain the difference. Low volume on EDD-heavy cases is a strength, not a weakness, but only if you frame it.

4What monitoring systems have you worked with?

Name the platforms and be precise about what you actually did in them — investigating alerts, writing case narratives, running queries, extracting outcome data, testing scenarios, or configuring rules. Those are very different levels.

If your exposure was as a user rather than an administrator, say that plainly. Interviewers respect the distinction and will find it out anyway.

Where you have used more than one platform, mention what differed between them — that shows you understand the underlying logic rather than just one interface.

5Have you drafted SARs, and how many?

Be honest about your role: drafted, contributed to, or escalated for someone else to draft. All three are legitimate at different levels.

Then pivot to what makes a good one, because that is the real question behind it — clear reasoning the FIU can follow, what you ruled out and why, and specific detail on amounts, dates, counterparties and jurisdictions.

If you have had feedback from an MLRO on your narratives, mention it. That signals your drafting was reviewed rather than simply accepted.

6Have you been involved in scenario tuning or model validation?

Describe your role precisely — providing outcome data by scenario, testing proposed thresholds against historical data, below-the-line sampling, or owning a change through governance.

If you only supplied data, say so, but explain what the data showed and what it led to. Understanding why a threshold moved is more valuable than having pressed the button.

If you have no exposure, say you have not been involved directly but explain how you would approach it — that answers the underlying question about whether you think at control level.

7Have you supported a regulatory examination or lookback?

Explain what triggered it, your role, and crucially what you learned about how files are assessed under scrutiny. Anyone who has had their cases sampled by an examiner understands documentation standards differently afterwards.

If you were part of a remediation population, describe the scope and what the root cause turned out to be.

If you have no direct experience, say so and mention any internal audit or QA exposure instead — the principle is the same.

8What is your SAR conversion rate and what does it tell you?

Give the figure if you have it, then interpret it. A very low conversion rate may indicate poorly tuned scenarios generating noise, or that alerts are being escalated without proper analysis. A very high one may suggest under-detection — the system only catching the obvious — or defensive reporting.

The point you want to land is that you monitor it and treat it as a signal about the control, not as a personal performance metric.

If you do not track it, say you would want to, and explain what you would use it for.

9Have you specialised in any typology or sector?

Name it — trade-based laundering, crypto, correspondent banking, fraud-linked laundering, sanctions-adjacent activity — and give a concrete example of a case in that area.

Explain what makes that typology hard to detect, because that demonstrates the specialism rather than just claiming it.

If you have not specialised, frame your breadth positively but pick the area you would want to develop, so the answer still shows direction.

10Tell me about a case you got wrong.

Pick something genuine but not catastrophic — a closure later reopened, a connection you missed that a colleague spotted, or an escalation that was clearly premature.

Structure it as: what you concluded, why that seemed reasonable at the time, how it surfaced, and what changed in your approach afterwards.

The last part is what they are listening for. An error that produced a lasting change in how you work is a strength; one you simply regret is not.

Avoid blaming systems or colleagues, even where they contributed.

11Why are you leaving your current role?

Give a reason rooted in what you want next — greater complexity, ownership of a control, a specialism, or a step toward leadership.

Criticising your current employer, however justified, raises questions about your discretion — particularly in compliance, where discretion is the job.

If the real reason is negative, translate it. "The role had become largely process with limited investigative work" is honest without being disloyal.

12What are you looking for in your next role?

Name the scope you want — running investigations end to end, owning tuning or scenario design, managing a team, or moving toward MLRO.

Connect it to what this role offers, which requires having read the job description properly.

If you want a step up, say so directly rather than hinting. Ambiguity here often reads as lack of ambition.

13How do you structure a complex investigation?

I start by establishing the customer baseline, because without knowing what is expected I cannot judge what is anomalous. That means occupation or business type, declared turnover, expected activity, geography and risk rating.

Then I define the actual question. An alert tells me a threshold was crossed; it does not tell me what is suspicious. Framing the question — is this money moving without economic purpose, is the counterparty unexplained, is the scale inconsistent with the business — keeps the investigation focused rather than sprawling.

Next I map the flows: where funds come from, where they go, in what amounts, and over what period. Visual mapping helps on networks.

Then I test the most plausible legitimate explanation first, rigorously, before testing alternatives. If the innocent explanation survives scrutiny, I have my answer.

Throughout, I document as I go rather than reconstructing at the end, because reasoning written retrospectively tends to look tidier than it was.

14How do you avoid confirmation bias?

The main discipline is testing the innocent explanation as rigorously as the suspicious one. In practice that means actively trying to prove the activity legitimate, not just noting that it might be.

The question I ask myself is what evidence would change my conclusion. If the honest answer is nothing, I am not investigating — I am building a case for a position I already hold.

I also watch for the sequencing trap. Once you form a hypothesis, subsequent facts get read as supporting it. So I try to gather the facts before forming a view, and where I have formed one early, I deliberately look for the contradicting evidence.

Documenting what I ruled out and why helps, because it forces me to have actually considered alternatives rather than assuming them away.

And on significant cases I ask a colleague to look at the evidence without my conclusion attached, since a second reading without the framing is genuinely useful.

15How do you investigate a network rather than a single account?

The shift is from asking whether this account's activity is explained to asking what the connected pattern is doing.

I link accounts on whatever data is available — shared counterparties, addresses, phone numbers, devices, IP addresses, onboarding period, and timing patterns. Common beneficiaries are usually the strongest link, because that is where separate flows converge.

Then I aggregate. Individually unremarkable amounts can total substantially, and a network's significance is almost always in the aggregate rather than any single account.

I look for structure: is this collection and forwarding, distribution from a single source, or circular movement? Each shape suggests a different purpose.

Crucially I do not close any individual account's alert on its own merits while the network question is open, because that is how networks get dismissed one file at a time.

I escalate it as a linked case with the connections mapped, since the linkage is the intelligence.

16What is link analysis and when do you use it?

It is mapping relationships between entities — accounts, individuals, counterparties, addresses — to reveal structures that are invisible transaction by transaction.

I use it whenever I suspect coordination rather than isolated behaviour: mule networks, layering chains across multiple accounts, or cases where the same beneficiary appears behind several customers.

The practical value is that it surfaces the thing you were not looking for. Reviewing one account, a payment to an unfamiliar beneficiary is a single data point. Mapped across twelve accounts, the same beneficiary receiving from all of them is the finding.

It also helps with scale — a network of thirty accounts is genuinely hard to hold in your head, and visualising it makes the structure obvious.

The limitation is data quality. Link analysis is only as good as the identifiers available, so incomplete counterparty data undermines it significantly.

17How do you investigate trade-based money laundering?

I start with the documents rather than the payment, because trade-based laundering is usually detectable through documentary inconsistency rather than transaction pattern.

Pricing is the first check — comparing invoice values against market rates using commodity data or trade databases. Over- or under-invoicing is the core technique, and a demonstrable pricing gap is concrete evidence rather than impression.

Then commercial coherence: do the goods make sense for the buyer's business, is the quantity plausible, does the shipping route make economic sense, and do the parties plausibly trade in those goods.

I cross-check documents against each other — invoice against bill of lading against packing list. Mismatches in quantity, description or party are significant.

I also look for repetition: the same goods invoiced multiple times, or a consistent pattern of over-pricing with one counterparty.

Related parties transacting at off-market prices is far stronger than an arm's-length deal, so I check the relationship between buyer and seller.

18What makes trade-based laundering hard to detect?

Several things compound. The transactions look entirely commercial — there is a buyer, a seller, goods and an invoice, so nothing appears anomalous on the payment leg alone.

Banks usually see only part of the picture. In open account trade we may see a payment with no supporting documents at all, which makes documentary analysis impossible.

Documentation is paper-based and easy to falsify, and verifying a bill of lading or an invoice against reality is genuinely difficult.

Pricing analysis requires sector knowledge. Knowing whether a price for specialised industrial equipment is inflated is not something an analyst can assess without reference data.

And the volumes are large — trade finance operations process significant transaction counts, so detailed review of every transaction is impractical.

Which is why detection tends to rely on targeted risk-based review and documentary inconsistency rather than transaction monitoring in the conventional sense.

19How do you investigate suspected mule activity?

I start with the profile mismatch, because that is usually the clearest signal. Credits from multiple unrelated senders into an account whose holder has no reason to receive money from many people — a student, someone on a modest fixed income, or a recently opened personal account.

Then the velocity. Mule accounts characteristically forward or withdraw funds quickly, retaining little. Money sitting suggests something else.

The extraction method matters: cash withdrawal ends the trail entirely, which is more concerning than onward transfer.

I check whether the senders or beneficiaries appear against other accounts, because mule networks rarely involve a single receiving account. Finding the same counterparties elsewhere turns one case into a network.

I also look at account age and any recent changes to contact details or access location, since takeover produces a similar pattern with a different explanation.

And I bear in mind the holder may be a victim rather than an organiser — which affects handling and contact, though not the reporting obligation.

20How do you approach crypto-linked investigations?

I focus first on the fiat legs, because that is where identity attaches and where our data is strongest. Who funded the purchases, how much, and does the scale match the customer's declared means.

Then I use blockchain analytics for what it does well: wallet clustering, exposure scoring, and identifying counterparty services. What I am looking for is whether funds touch mixers, unregulated exchanges, darknet markets, or sanctioned addresses.

I am careful with exposure findings. Direct exposure is significant; distant indirect exposure is common and affects innocent users, so I weight by proximity and proportion rather than treating any exposure as equivalent.

Platform regulation matters — funds from a licensed exchange have passed through some controls; funds from an unregulated one have not.

I also check Travel Rule data completeness on incoming transfers, since missing originator information is both a red flag and a practical obstacle.

Pseudonymity is a limit, not a dead end — the on- and off-ramps are where the analysis lands.

21How do you handle a case where the explanation is plausible but unverifiable?

Unverified is not verified, and I try to be disciplined about not letting a comfortable narrative close a case.

First I test how hard I have actually tried. Most explanations leave some trace — a property sale has a completion statement, an inheritance has probate, a business receipt has an invoice. A customer with a genuine explanation can usually point to something.

If evidence genuinely cannot be obtained, I assess materiality. An unverified explanation for a modest amount on a low-risk customer sits differently from an unverified explanation for a large payment on a high-risk one.

I test internal consistency too — does the explanation fit the amount, timing, sender and what we already know about the customer? Explanations that are plausible in isolation often do not fit the specifics.

Then I document the explanation, the fact it could not be corroborated, and my reasoning. Where it remains unexplained on something material, that supports escalation rather than closure.

22How much weight do you give a customer's explanation?

It is evidence to be assessed, not an answer that ends the enquiry.

I weigh it on three things. Internal consistency — does it explain all the features of the activity, or just the one I asked about? Consistency with what we independently know — does it fit their profile, history and other transactions? And corroboration — is there anything supporting it beyond the assertion?

The manner of the explanation matters too. A straightforward account given readily reads differently from one that shifts under questioning, or that expands each time a new detail is raised. Explanations that adapt to fit new information are a signal in themselves.

I am also conscious that a good explanation is exactly what someone laundering money would prepare. Fluency is not evidence.

So I treat it as a hypothesis to test rather than a conclusion to accept, and I document both what was said and what supported it.

23What sources do you use beyond internal data?

Internal data tells me what happened but rarely why, so external sources usually carry the analysis.

Corporate registries for verifying counterparties, ownership and directorships — often the fastest way to test whether a stated commercial relationship is plausible.

Adverse media and court or enforcement records, for context on the customer or their counterparties.

Sanctions and PEP data, including checking counterparties rather than just the customer.

Blockchain analytics where crypto is involved, and trade or commodity pricing data for trade cases.

Open-source research more broadly — company websites, filings, industry sources — to test whether a business exists and does what it claims.

The discipline is recording what I searched and what I found, including negative results. "Counterparty not found on any registry" is a finding worth documenting, not an absence to leave silent.

24How do you decide when an investigation is complete?

When I can either explain the activity with evidence, or articulate clearly why it cannot be explained. Those are both complete positions.

What completeness is not is exhausting every possible line of enquiry. There is always another search, and a case can expand indefinitely if you let it.

The test I apply is whether another analyst reading my work could follow the reasoning and reach the same conclusion. If there is an obvious question I have not answered, it is not finished.

I also check proportionality — the depth should match the risk. A modest alert on a low-risk customer does not warrant the same work as a high-value case on a high-risk relationship.

Where I cannot resolve something material, that is a complete investigation with an unresolved element, and it goes up. That is different from an incomplete one.

25How do you handle historical activity discovered mid-investigation?

I expand the review period to follow the conduct rather than staying within the alert window.

The alert period is a system artefact — it reflects when a threshold was crossed, not when the behaviour started. If a pattern runs back two years and I only examine two months, I materially understate it, and the truncated view often looks far less significant than the whole.

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

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

If no alerts fired across a period where the pattern was present, that is a detection gap, and I would raise it separately from the case.

26What do you do when data you need is missing?

I request it internally first — often the information exists in another system or with the relationship team and simply is not in the case record.

Where it genuinely is not available, I note the limitation explicitly in the case rather than working around it silently. A conclusion reached without key data should say so, because the next reader needs to know what the assessment rests on.

Then I assess whether I can reach a defensible position without it. Sometimes the missing element is not material; sometimes it is the whole question.

The more important step is checking whether the gap is systemic. If counterparty details are missing on this case, they are probably missing across a population, and that is a control issue rather than a case issue.

Analysts compensating manually for data gaps is not a control — it hides the problem. So recurring gaps get escalated as data quality findings.

27How do you assess whether a business rationale is genuine?

I test it against observable reality rather than assessing whether it sounds plausible, because most rationales sound plausible.

Does the counterparty exist and trade in what is claimed? Registries, websites and filings usually answer that quickly.

Do the volumes match the stated business? A company claiming to supply a niche product should not be moving amounts inconsistent with that market.

Does the routing make commercial sense? Payments via jurisdictions that add cost without function need explaining.

Does the pricing hold up against market data?

And does the economic logic work — is anyone actually better off, or is money moving in a circle achieving nothing?

Rationales tend to collapse quickly under third-party checking. The ones that survive verification against independent sources are usually genuine, and that is a more reliable test than assessing coherence in isolation.

28How do you handle an investigation involving a colleague or internal party?

I would step out of the normal process entirely, because the standard route may involve the person concerned or people connected to them.

First I would declare any personal connection and not work the case myself if there is one.

Then route it through the appropriate function — internal fraud, security, or whistleblowing — rather than the usual AML escalation path.

I would not discuss it with the team, and I would be careful about my immediate manager if there is any possibility of connection.

I would document what I observed factually — specific actions, dates, cases — without characterising motive, because I do not know it and the suspicion may be wrong.

And I would avoid doing my own investigation beyond what my role requires. Accessing records outside my remit could itself breach policy and could compromise a formal investigation.

Confidentiality matters more here than anywhere, both to protect the process and to be fair to the colleague.

29What is your approach to prioritising a case queue?

Risk-weighted rather than first in, first out — because chronological processing means a high-risk case from today sits behind low-risk ones from three weeks ago.

The factors I weight are customer risk rating, transaction value, sanctions adjacency, whether the customer has prior escalations, and any regulatory or internal deadline.

Sanctions adjacency goes first regardless of value, because the consequences and timelines are different.

I also watch ageing separately, because a purely risk-based approach can leave older low-risk cases indefinitely, and unmanaged backlogs are themselves a finding. So there needs to be a mechanism that pulls aged items through.

Where volume exceeds capacity consistently, I would rather complete fewer cases properly and report the shortfall than process everything to a standard that would not survive review.

Rushed closures do not reduce work — they defer it into remediation.

30How do you know your investigation quality is good?

Through external validation rather than self-assessment, because everyone believes their own work is sound.

QA outcomes are the most direct measure — what proportion of my closures pass sampling, and what the recurring feedback themes are.

Whether my escalations are upheld tells me about my judgement threshold. A high proportion converting to reports suggests I am escalating the right cases; a low proportion suggests I may be passing decisions upward rather than making them.

Whether any of my closures are later reopened is the most uncomfortable but most useful signal.

Feedback from the MLRO on narrative quality matters, since a well-reasoned escalation that they can act on without redoing the work is the standard.

I would also want to compare against peers on similar portfolios, because an individual metric means little without context.

31How do you approach scenario tuning?

I start from outcome data rather than alert volume, because volume alone tells you nothing about whether a scenario is working. What I want is the escalation and SAR conversion rate by scenario — which ones actually produce findings and which generate noise.

Then I look at segmentation before touching thresholds. Most poor performance comes from applying one threshold across dissimilar customer populations, so a rule calibrated for retail customers misfires constantly on trading businesses. Fixing segmentation often improves performance more than moving the threshold.

Any proposed change gets tested against historical data first — running the new logic retrospectively to see what it would have caught and what it would have missed.

Then below-the-line sampling to confirm the new threshold is not leaving genuine risk undetected.

And it goes through documented change governance with the evidence attached. Undocumented tuning is one of the more serious governance findings, because it means nobody can demonstrate why the system is calibrated as it is.

32What is below-the-line testing and why does it matter?

It is sampling transactions that fell just below a threshold and therefore never alerted, to check whether genuine risk is being missed.

It matters because it is the only way to test the one thing you cannot otherwise see. Alerts tell you what the system found; they tell you nothing about what passed underneath. A scenario with a perfect escalation rate might still be missing most of the risk if the threshold is set too high.

Practically I would sample transactions in a band below the threshold, review them as though they had alerted, and count how many would have warranted escalation.

If the answer is none, the threshold is defensible. If several look suspicious, it is set too high and needs lowering, with the sampling evidence supporting the change.

Regulators expect to see this. A threshold that has never been tested below the line is effectively an assumption, and "it was inherited" is not a defence in an examination.

33How would you reduce false positives without weakening detection?

The first place I look is customer data quality, because a large share of false positives comes from poor or missing customer information rather than the scenario logic. If expected activity is unrecorded or the profile is stale, the system has nothing sensible to compare against.

Second is segmentation. Grouping customers by expected behaviour — retail, corporate, by sector or turnover band — so thresholds reflect what is normal for that group typically removes a great deal of noise without touching detection at all.

Third is refining the scenario logic itself: adding conditions that distinguish the risk pattern from the legitimate one, rather than relying on value alone.

What I would avoid is simply raising thresholds across the board. That reduces alerts and detection in equal measure, and it is the easy answer that creates the gap.

Any change gets validated with below-the-line testing, so the reduction is evidenced rather than assumed.

34What is customer segmentation in monitoring?

It is grouping customers with similar expected behaviour so that thresholds and scenarios reflect what is normal for that group rather than a single average.

The reason it matters is that a threshold calibrated for a salaried individual will alert constantly on a business with legitimate high turnover, while the same threshold on that business may be so far below its normal activity that genuinely unusual behaviour never triggers. One setting produces noise at one end and blindness at the other.

Segments are typically built on customer type, sector, turnover band, product usage and geography.

Done well, it improves both sides of the equation simultaneously — fewer false positives on high-turnover customers and better detection on low-turnover ones.

The practical constraint is data. Segmentation depends on accurate customer information, so a firm with poor KYC data cannot segment effectively, which is one of the ways weak KYC undermines monitoring.

35How do you demonstrate scenario coverage is adequate?

By mapping scenarios against the typologies identified in the enterprise-wide risk assessment, and showing that each material risk has detection logic behind it.

That mapping is what an examiner asks for. If the risk assessment names trade-based laundering as a material risk and no scenario addresses it, that gap is visible immediately and is difficult to explain.

I would also test coverage rather than assert it — sampling activity in segments that rarely alert, to check whether the silence reflects low risk or absent detection.

Data completeness is part of coverage too. A scenario that exists but runs on incomplete data provides no coverage in practice, so I would verify the feeds support the logic.

And coverage needs revisiting when products, markets or customer mix change. Coverage adequate two years ago may have gaps now, and that drift is a common finding.

36What is model validation and who should perform it?

It is independent testing that the monitoring system does what it is supposed to do — that scenarios fire correctly, data feeds are complete and accurate, thresholds are appropriate, and coverage matches the assessed risk.

The independence requirement is the key point. It cannot be performed by the people who own or built the model, because they are testing their own assumptions. Typically it sits with a separate validation function, internal audit, or an external firm.

It should happen periodically and on material change — a new scenario, a significant threshold move, a new data source, or a new product.

What it examines in practice: whether the logic performs as designed against test data, whether outcomes justify the calibration, whether documentation supports the choices made, and whether identified issues from previous validation were actually fixed.

Validation that consistently confirms everything is fine without testing anything is itself a finding.

37What are the risks of incomplete data feeds?

Silent failure, which is the most dangerous kind because there is nothing to notice.

If a transaction type is not flowing into the monitoring system, no scenario runs against it and no alert is ever generated. From the outside that looks identical to a population with no suspicious activity — the reports show zero alerts either way.

Missing fields have the same effect at a narrower level. Absent counterparty data disables network and beneficiary logic; missing geography disables jurisdiction rules.

The consequence is undetected risk with no indicator that it is undetected, which is why several enforcement cases involve firms that believed their monitoring was working for extended periods.

The control is data completeness testing — reconciling what enters the monitoring system against source systems, and monitoring alert volumes for unexplained drops. An absence of alerts should itself trigger attention rather than reassurance.

38How would you identify a detection gap?

Gaps do not announce themselves, so it has to be deliberate rather than reactive.

The most structured method is mapping typologies from the risk assessment against active scenarios and looking for risks with no corresponding logic.

Then I would look at where SARs originate. If a meaningful proportion come from staff referrals, relationship managers or external sources rather than the monitoring system, that indicates the system is not catching what it should.

Cases identified externally — by law enforcement, another institution, or media — are the strongest evidence of a gap, because someone else detected what we did not.

Below-the-line testing addresses threshold gaps specifically.

And manual sampling of segments that rarely alert tests whether the silence is genuine.

The mindset that matters is asking what is not being detected, rather than reviewing what is. Most reporting answers the second question and never the first.

39What is your view on machine learning in monitoring?

It has real value in specific places, and I would be careful not to present it as either a solution or a threat.

Where it works well is alert prioritisation — scoring alerts by likelihood so analysts work the highest-value ones first — and anomaly detection that finds patterns fixed rules would not describe in advance. It can also meaningfully reduce false positives.

The constraints are explainability and governance. If a model escalates something, we need to be able to explain why to an examiner, and "the model scored it highly" is not sufficient. Rule-based logic remains attractive precisely because it is transparent.

There is also a training data problem: a model trained on historical outcomes learns to find what we already caught, which can entrench existing blind spots.

Most firms therefore run it alongside rules rather than replacing them, and treat it as a prioritisation and augmentation layer rather than the primary detection control.

40What are the governance requirements for a machine learning model?

Broadly the same as any model, with additional attention to explainability and drift.

Documented development — what data it was trained on, what the model does, what assumptions underpin it, and what it is not designed to detect.

Explainability of outputs, so a decision can be justified rather than merely reported. That is a regulatory expectation as much as a technical one.

Independent validation before deployment and periodically thereafter, testing performance against held-out data rather than the training set.

Ongoing performance monitoring for drift, because a model trained on past behaviour degrades as behaviour changes — and drift is gradual and easy to miss.

Bias testing, since a model can systematically under-detect in populations underrepresented in training data.

And a fallback: what happens if the model degrades or fails. Running it as the sole detection layer without a rules-based safety net is a concentration risk.

41How do you handle a scenario producing almost entirely false positives?

I would analyse before acting, because the obvious response — switching it off — is often wrong.

First, why is it misfiring? A high false positive rate frequently reflects poor segmentation rather than flawed logic. The scenario may be sound but applied to a population it was never calibrated for, in which case segmentation fixes it without losing detection.

Second, has it 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 addresses.

That is the decisive question: what risk does it address, and is anything else covering it? Retiring the only detection for a typology creates a coverage gap even if the scenario performs badly.

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

42Who should approve a tuning change?

It should go through formal model change governance rather than being made operationally.

In practice that means a documented proposal with the rationale and supporting analysis, review by the second line, and approval at a level proportionate to the change — material threshold moves or scenario retirement needing senior sign-off.

Analysts should never adjust thresholds unilaterally, even where they can see a scenario is misfiring. The reason is that tuning changes what the firm detects, which is a control decision rather than an operational one.

Documentation matters as much as approval. An examiner will ask why a threshold is set where it is, and the answer needs to be an evidenced decision rather than institutional memory.

I would also expect post-implementation review — checking after the change whether the predicted effect actually occurred, since tuning decisions are frequently made on modelled assumptions that do not hold in production.

43How do you manage an alert backlog?

Three things in parallel: protect coverage, fix the cause, and report honestly.

Protecting coverage means triaging by risk rather than working chronologically, so the highest-exposure alerts are reviewed while the backlog is addressed. Letting everything age equally means high-risk cases sit alongside noise.

Fixing the cause requires diagnosing it correctly, because the remedies are different. Poor tuning generating excessive volume is not solved by adding analysts. Genuine capacity shortfall is not solved by tuning. A data issue creating spurious alerts is solved by neither.

Reporting honestly is the part firms get wrong. Backlogs become regulatory findings not because they exist but because they were concealed or left unaddressed.

I would also put ageing metrics in place going forward, so the position is visible continuously rather than discovered periodically.

44What management information would you use to run a monitoring function?

Scenario-level outcome data first, because it is the most actionable — alert volumes, escalation rates and SAR conversion by scenario. That tells you which parts of the system are working and which are generating noise.

Ageing and backlog position, with trend rather than a point-in-time figure.

QA pass rates, broken down by analyst and by case type, since a pattern by case type indicates a training or standards gap rather than individual performance.

Data completeness metrics, because those are the early warning for silent failures.

Tuning change history, so decisions are traceable.

And where alerts come from relative to SARs generated by other routes — a rising proportion of reports originating outside the system points to a detection gap.

What I would avoid is reporting that emphasises throughput. Cases closed per analyst measures activity, not effectiveness, and optimising for it degrades quality.

45How do real-time and post-event controls complement each other?

They address different problems and neither substitutes for the other.

Real-time screening intercepts a transaction before it completes, which is essential where the requirement is prevention — sanctions above all, since a completed payment to a designated party is a breach regardless of what happens afterwards.

Post-event monitoring reviews activity after settlement, usually in batch, and detects behavioural patterns that only become visible over time. Structuring, layering and network activity are invisible in any single transaction and only emerge across a period.

So real-time answers "should this specific payment proceed" and post-event answers "does this pattern of behaviour make sense".

The balance is shifting with instant payments, where irrevocable settlement means post-event detection cannot recover funds. That pushes more weight onto real-time controls and onto detecting mule accounts at onboarding rather than after the fact.

46What monitoring challenges do instant payments create?

The core problem is that settlement is immediate and irrevocable, so the intervention window essentially disappears.

With traditional transfers there is usually time between initiation and settlement in which a control can act. With instant payments, by the time an overnight batch alert generates, the money has moved on — often through several accounts.

That changes what detection achieves. It still produces intelligence and supports reporting, but it no longer prevents loss, which matters particularly for fraud-linked laundering where victims' funds are involved.

It also accelerates layering. Funds can pass through multiple accounts within minutes, which compresses the timeframe for network detection.

The practical responses are stronger real-time controls, behavioural profiling that flags anomalies at initiation, better mule detection at onboarding, and faster inter-institution information sharing where the framework permits it.

47How do you monitor correspondent banking activity?

The fundamental constraint is that you cannot see the underlying customers — you are monitoring another institution's flows, so the analysis works at pattern level rather than customer level.

I would look at whether the payment patterns match what the respondent said their business is: expected corridors, currencies, volumes and counterparty types. Activity in jurisdictions they never mentioned is the clearest signal.

Nesting is a specific concern — indications that other institutions are accessing our services through the respondent, which means exposure to customers two steps removed.

I would watch for volumes inconsistent with the respondent's stated size, sudden pattern changes, and payments involving higher-risk jurisdictions.

Because visibility is limited, the respondent's own controls are effectively the control. So monitoring findings feed back into periodic reassessment of their programme, and persistent anomalies are a relationship question rather than just a transaction one.

48How would you build monitoring for a new product?

Starting from risk rather than from available data, and before launch rather than after.

First, a risk assessment of how the product could be abused — what makes it attractive to a launderer. Speed, anonymity, cross-border reach, cash access and high value all matter.

Then translating those risks into typologies: what would abuse actually look like in transaction terms.

Then designing scenarios against those typologies, and — this is the step commonly missed — confirming the data required actually exists and flows into the monitoring system. Scenarios cannot run on data that is not captured, and retrofitting data capture after launch is expensive.

Then testing before launch against simulated or pilot data.

The governance point is that this should be part of product approval. A product launching without monitoring coverage is an active exposure, and firms that discover this after go-live usually find it takes months to remediate.

49What makes a high-quality SAR narrative?

Reasoning the reader can follow without redoing the investigation.

Structurally I would cover: who is involved, what happened, why it is suspicious, and the supporting detail. The "why" is the part that distinguishes a good narrative — a transaction list with a conclusion attached is not analysis.

I would state the customer's expected profile, what actually occurred, and why the two are inconsistent. That contrast is usually the substance of the suspicion.

I would include what explanation was offered or sought, what I verified, and what I could not — because what was ruled out tells the reader as much as what was found.

Specific detail matters: amounts, dates, counterparties, jurisdictions, account numbers. Investigators use those to link across reports.

And I would avoid overstating. Saying activity is unexplained is accurate; asserting the customer is laundering money is a conclusion the institution is not in a position to reach.

50What are common weaknesses in SAR narratives?

The most common is the transaction dump — pages of transaction detail with no interpretation, leaving the FIU to work out what the concern is. That transfers the analysis rather than performing it.

Second is conclusions without supporting facts: stating the activity is consistent with laundering without setting out what specifically makes it so.

Third is omitting what was ruled out. A narrative that does not mention the explanation offered and why it was rejected looks like the alternative was never considered.

Fourth is internal jargon — scenario codes, system references and abbreviations that mean nothing outside the institution.

Fifth is vagueness on identifiers. "Multiple transfers to overseas accounts" is far less useful than the actual amounts, dates and destinations, because the specifics are what allow linking across reports.

And occasionally the opposite problem — a narrative so hedged that the actual suspicion is never clearly stated.

51What is the threshold for reporting?

Reasonable suspicion — a reasonable basis to suspect the activity may involve criminal property or purposes. Not proof, not certainty, and not a balance of probabilities.

The practical test I apply is whether I can articulate the grounds. If I can set out the specific facts, why they are inconsistent with the customer's profile, and why the innocent explanation does not hold, that is reasonable suspicion. If all I have is discomfort I cannot explain, it is not.

That distinction matters in both directions. Waiting for proof would mean almost nothing gets reported, because institutions rarely have evidence in an evidential sense — we see transactions, not conduct.

Equally, reporting on generic unease floods the FIU with material of no intelligence value.

So the standard is articulable grounds, and the discipline is being able to write them down clearly enough that another reasonable person would reach the same view.

52What is defensive reporting and why is it a problem?

It is filing reports to protect the institution rather than because suspicion genuinely exists — reporting anything ambiguous on the basis that a report can never be criticised.

The problem is that it degrades the regime. FIUs have finite analytical capacity, and a high volume of low-value reports buries the ones that matter. If genuine intelligence sits alongside thousands of marginal filings, the effect is to hide it.

It also masks weak analysis internally. An institution reporting everything ambiguous is not making judgements, and its escalation process is doing no filtering.

Regulators have criticised it specifically, which surprises people who assume more reporting is always safer.

The remedy is better analysis rather than a lower reporting rate as a target. If a case is genuinely unexplained after proper investigation, report it. If it was never properly investigated, investigate it rather than reporting to close it.

53How do you decide between closing and escalating a borderline case?

The test is whether the activity has an explanation supported by evidence and consistent with what we know about the customer. If it does, I close with reasoning. If it does not, I escalate.

Where it feels borderline, that usually means one specific element is unresolved rather than the whole picture being ambiguous. So I try to name it — an unidentified counterparty, an amount that does not reconcile, an explanation I could not corroborate.

Once named, it is usually clear whether it is material. An unverified detail on a peripheral point is different from an unexplained source of funds.

Where it remains genuinely balanced, I escalate — but as a referral for decision, setting out the arguments each way rather than asserting suspicion I do not hold. That is more useful to the MLRO than either a bare escalation or false confidence.

If I find myself escalating a high proportion of cases, that is a signal about my threshold or the tuning, and I would want to know which.

54What is continuing activity reporting?

Filing further reports where suspicious activity persists after an initial SAR, typically on a defined cycle rather than for every subsequent transaction.

The purpose is that the FIU sees the ongoing position rather than a single snapshot. A report filed six months ago describing a pattern that has since continued or escalated gives an incomplete picture without an update.

Practically it means monitoring the relationship after filing rather than closing the file and moving on, and reporting again where the pattern continues, changes materially, or new counterparties appear.

The cycle varies by jurisdiction and firm policy — commonly ninety days where activity is ongoing.

What it should not become is mechanical refiling of identical content. A continuing report should say what has changed, what has continued, and what if anything is new, otherwise it adds nothing.

55How do you handle the relationship after filing?

By continuing to service and monitor it as normally as possible, which is uncomfortable but usually correct.

Exit is not automatic. Authorities sometimes prefer relationships to continue so activity can be observed, and abrupt closure can prejudice an investigation or amount to tipping off.

So operationally: continue monitoring with heightened attention, file continuing reports where the pattern persists, and avoid any change in service the customer would find inexplicable.

Customer contact needs care. Questions that would be routine in another context can disclose when a report exists, so I would follow approved wording and take guidance before making enquiries.

Internally, information stays with those who need to know. Discussing it more widely risks disclosure and serves no purpose.

And the file should record the position clearly, so anyone picking it up understands the context without having to ask around.

56When would you recommend exiting a customer after a SAR?

Where the risk is genuinely unmanageable rather than simply because a report was filed.

The factors I would weigh: whether the suspicious pattern is continuing, whether the customer has been cooperative on information requests, whether we can monitor the relationship effectively, and whether the underlying concern is a one-off or systemic to how they operate.

A single unexplained transaction on an otherwise transparent relationship is different from a customer whose entire activity we cannot explain and who resists every enquiry.

The critical point is timing and process. Exit can prejudice an investigation, so the decision should involve the MLRO, and in some cases authorities will indicate a preference.

Exit also has to be executed carefully to avoid tipping off — a customer told their account is closing because of suspicious activity has effectively been informed.

And I would want the rationale documented, since blanket exit after any report is a de-risking pattern regulators criticise.

57What is a consent or DAML request?

It is a request to the FIU for permission to proceed with a transaction that would otherwise risk committing a money laundering offence — where the institution suspects the funds are criminal property but the customer has instructed a payment.

The mechanism exists because without it, a firm suspecting criminal property would face a choice between committing an offence by dealing with it and effectively tipping off by refusing.

Terminology and process vary — the UK framework uses defence against money laundering requests; other jurisdictions have equivalents.

The timing obligations are strict, usually with a defined notice period and a moratorium if consent is refused, so these are handled by the MLRO rather than at analyst level.

Practically, the transaction is held pending the response, and customer communication during that period is tightly constrained — which is often the hardest operational aspect.

58How do you handle a request for information from law enforcement?

I would not respond substantively myself. I would take the details and route it through the proper channel — the MLRO, legal, or a dedicated law enforcement liaison function.

The reasons are practical. The legal basis needs verifying, the authenticity of the requester needs confirming, and the permissible scope of disclosure needs assessing. Providing customer information without proper basis breaches confidentiality and data protection obligations.

Impersonation of law enforcement is also a recognised technique for obtaining customer information, so verification matters.

I would be courteous rather than obstructive — take contact details, explain that requests are handled through a specific channel, and pass it on promptly.

I would not inform the customer, since that could prejudice an investigation and may constitute tipping off.

And I would record that the contact occurred, because the fact of law enforcement interest is itself relevant to the customer's risk position even if no disclosure follows.

59What is tipping off and where do people go wrong?

It is disclosing, directly or indirectly, that a report has been made or is being contemplated, or that an investigation is underway. It is a criminal offence in most jurisdictions because it allows subjects to move funds or destroy evidence.

The common failure is not deliberate disclosure but improvisation. Staff asked why a payment is delayed invent an explanation, and in trying to be helpful they signal that something specific is happening.

Another is inconsistency — being open in ordinary cases and evasive where a report exists. The pattern itself discloses, which is why the approved wording has to be used consistently regardless of the facts.

A third is internal: discussing cases with colleagues who have no need to know, or in open areas.

And a subtle one is behavioural — sudden changes in service, unusual documentation requests, or a relationship manager going quiet, all of which a customer can read.

60How do you measure SAR quality?

Through structured internal review rather than volume, because volume tells you nothing about whether reports are useful.

Internal QA against a defined standard is the main mechanism — sampling filed reports and assessing whether the narrative explains the suspicion, includes the necessary identifiers, states what was ruled out, and avoids unsupported conclusions.

MLRO feedback is valuable, since they see every report and can identify recurring weaknesses.

Some jurisdictions provide feedback from the FIU on report quality or usefulness, which is the most direct external measure where available.

I would also look at how often reports require follow-up requests, since that suggests the original was incomplete.

What I would not use is conversion or acknowledgement rates as a quality proxy — a report can be excellent and lead nowhere, or thin and coincide with an investigation already underway.

61What would you do if the MLRO declined to file on a case you believed warranted it?

First I would make sure I had presented it properly. Sometimes a decision reflects my not having articulated the reasoning clearly rather than a genuine difference of view, so I would set out the evidence and analysis in writing.

If they still declined after seeing that, I would accept it. The MLRO owns the reporting decision, they see the whole portfolio, and they may have context I lack.

What I would ensure is that my assessment remains documented in the case record rather than existing only in a conversation. That protects the institution's record and my own position.

Where I would go further is if I believed the decision was not a legitimate judgement but a failure to consider the evidence, or was driven by commercial pressure. In many jurisdictions individuals carry personal exposure for failing to report, so I would use the escalation route above the MLRO or whistleblowing procedures.

That is a serious step and not for ordinary disagreement.

62How do you ensure consistency in escalation decisions across a team?

Documented criteria first, because without a shared standard escalation becomes a function of individual risk tolerance. Two analysts on identical facts should reach the same conclusion, and where they do not, the criteria are unclear.

Worked examples are more effective than written criteria alone. A set of real cases with the reasoning explained gives analysts a calibration point that abstract guidance cannot.

Calibration sessions where the team assesses the same case independently and then compares reasoning surface divergence quickly, and the discussion is usually more valuable than the outcome.

QA sampling with feedback loops closes it, provided the feedback explains the reasoning rather than just recording a pass or fail.

I would also track escalation rates by analyst. Wide variation on similar portfolios indicates inconsistency rather than differing judgement, and it is worth investigating before an auditor does.

63What are the components of an effective AML programme?

The standard framework is senior management commitment, a documented risk assessment, policies and internal controls, customer due diligence, monitoring and reporting, independent testing, and training.

But listing them is the easy part. What makes a programme effective rather than merely present is whether the components connect. The risk assessment should drive control design; the controls should be calibrated to the assessed risks; testing should verify they work; and findings should change something.

The common failure is a programme where each element exists in isolation — a risk assessment that never informs scenario coverage, training that does not reflect the firm's actual risks, or testing that confirms procedures exist without checking they function.

Senior management commitment is the one people treat as boilerplate, but it determines resourcing and whether compliance can hold a position against the business. Without it, the other components degrade regardless of design.

64What goes into an enterprise-wide risk assessment?

Inherent risk assessed across customers, products, geographies and delivery channels; the controls mitigating each; and the residual risk that remains.

The residual step is where many assessments are weak. Identifying inherent risk is straightforward; demonstrating that a specific control actually reduces it, and by how much, requires evidence rather than assertion.

It should be granular enough to be useful. Rating an entire customer base as medium risk tells you nothing about where to focus.

It needs refreshing on a defined cycle and on material change — new products, new markets, acquisitions, or significant shifts in customer mix.

And critically it should drive decisions. An assessment that identifies a material risk with no corresponding control, and nothing follows, is worse than not having identified it — the firm has documented a known gap it did not address, which regulators treat as an aggravating factor.

65How does the risk assessment connect to monitoring?

Scenario coverage should map directly to the typologies the risk assessment identifies as material. That mapping is the link between what the firm says its risks are and what it actually detects.

In practice I would expect to see a coverage matrix — each material typology on one axis, the scenarios addressing it on the other. Gaps become visible immediately, and that is exactly what an examiner asks for.

It works in both directions. The risk assessment tells you what to detect; monitoring outcomes tell you whether the assessment was accurate. If a risk rated low is generating escalations, the rating needs revisiting.

The failure mode is the two documents living separately — a risk assessment refreshed annually by one team and scenarios maintained by another, with no reconciliation between them.

That disconnect is common and is one of the more reliably identified findings in examinations.

66What is the three lines of defence model in practice?

The first line owns and operates the controls day to day, the second sets policy and provides challenge, and the third gives independent assurance.

In practice the boundaries are less clean. AML operations may sit in the first or second line depending on structure, and what matters more than the label is whether genuine challenge exists.

The common failure is the second line functioning as an extension of operations — reviewing cases rather than challenging the framework, or approving what the first line proposes without independent assessment. When that happens the model exists on paper with two lines doing the same job.

Effective second line means the ability and willingness to say no: to override a business decision, to refuse a risk acceptance, or to escalate over the first line's objection.

Third line effectiveness depends on testing outcomes rather than process compliance. Audit confirming procedures exist adds little; audit testing whether controls actually detect risk adds a great deal.

67What does effective independent testing look like?

Testing whether controls work, not whether they exist.

Concretely that means sampling closed alerts and reassessing them independently, rather than checking that a case note was written. It means injecting known test cases to confirm screening and scenarios detect them. It means reconciling data feeds against source systems to verify completeness.

It should also test the things that fail silently — coverage gaps, dormant scenarios, and populations that never generate alerts.

And it must verify that previous findings were genuinely remediated rather than closed on a plan. Findings marked resolved where the underlying issue persists is a recurring and serious problem.

The independence requirement is real: testing performed by the function that owns the control is not assurance, whatever it is called.

Testing that consistently finds nothing is itself worth questioning, since no programme is that good.

68How would you respond to an audit finding you disagreed with?

Understand it precisely first, because disagreement often comes from a difference in scope or definition rather than substance. What exactly is the finding, what evidence supports it, and what standard is being applied?

If I believe it is factually wrong, I would provide evidence rather than argument — the case records, the data, the documentation that contradicts it. Auditors respond to evidence; they discount assertion.

If the point is valid, I would accept it. Disputing findings without basis damages credibility and makes future engagement harder, and audit will typically be right more often than not.

Where there is genuine disagreement on judgement rather than fact, I would say so clearly, document my position, and let it be recorded as a management response rather than escalating it into a conflict.

What I would avoid is accepting a finding I believe is wrong to close it quickly. That builds an inaccurate record and commits the firm to remediating a non-issue.

69What is a lookback review and when is it required?

A retrospective review of historical transactions to identify activity that should have been detected but was not — typically triggered by a control failure, a regulatory finding, or discovery of a detection gap.

They are usually imposed rather than voluntary, often as part of a settlement or supervisory action, and they are expensive because the population can span years.

Practically it means running current detection logic against historical data, reviewing what alerts, and filing reports where warranted.

The scoping is where the real work sits — determining the affected period, the population, and which scenarios apply. Too narrow and the review misses the point; too broad and it becomes unmanageable.

The relevant lesson for a programme is that identifying gaps internally and remediating them is far cheaper than having a regulator identify them and impose a lookback.

70How do you approach remediation of a known control gap?

Contain first, then fix the cause, then evidence the fix.

Containment means limiting ongoing exposure while the permanent solution is built — manual review, restrictions, or compensating controls. The gap continues until something changes, so interim measures matter.

Then assessing the affected population, since remediation usually has a backward-looking element as well as a forward-looking one.

Fixing the cause rather than the symptom is where programmes fail. Adding a manual check to catch what a broken control misses is not remediation; it is a workaround that will decay.

Evidencing the fix through testing is the step that gets skipped. A finding closed on implementation rather than on demonstrated effectiveness is likely to reopen.

And it should be tracked visibly with owners and deadlines, because regulators judge firms heavily on how they respond to issues they already knew about.

71What management information should reach the board?

Enough to discharge oversight responsibility, which means information that surfaces problems rather than presenting a clean picture.

Risk assessment outcomes and any material changes in the risk profile. SAR volumes and trends, with commentary rather than raw numbers. Alert backlogs and ageing. Control testing results including failures. Open regulatory and audit findings with remediation status. And resourcing pressure where it is affecting control effectiveness.

The commentary matters more than the metrics. A board seeing SAR volumes rise needs to know whether that reflects better detection, deteriorating customer quality, or defensive reporting — the number alone supports no decision.

What undermines board reporting is presenting only favourable metrics. Boards carry accountability, and a board that was never told about a backlog cannot be said to have overseen it.

Regulators examine board packs specifically to test whether management was informing or reassuring.

72How do you design effective AML training?

Role-specific and case-based rather than generic and definitional.

The failure mode is annual training covering the same general content for everyone — what money laundering is, the three stages, the obligation to report. Staff complete it and nothing changes, because it does not connect to what they actually do.

Front-line staff need to recognise indicators in their specific role and know how to escalate without tipping off. Analysts need investigative technique and documentation standards. Relationship managers need to understand why they cannot pressure for approval. Senior management need to understand what they are accountable for.

Case-based content works better than principles, because recognition is a pattern-matching skill and people learn it from examples.

I would also use real cases from the firm where possible, anonymised. Nothing lands like "this happened here."

And effectiveness should be measured through behaviour — referral quality and volume — rather than completion rates.

73How do you build a culture where staff actually escalate?

By making escalation safe and visibly valued, because the barrier is rarely knowledge — staff usually know they should report, and do not.

The main deterrents are fear of being wrong, fear of creating work, and a sense that nothing happens anyway.

So I would respond constructively to every referral including those that close, because an analyst who gets a dismissive response to a reasonable concern will not raise the next one.

I would never penalise a good-faith referral that turned out to be nothing. The cost of a false alarm is minutes; the cost of an unreported concern can be substantial.

Feedback matters — telling people what happened to what they raised, within confidentiality limits, so it does not feel like referrals disappear.

And visible support when someone holds a position against commercial pressure. Staff read what happens to colleagues who push back far more accurately than they read the policy.

74How do you resolve disagreement between compliance and the business?

By separating requirement from preference, because most disputes involve one side treating a preference as a requirement or a requirement as negotiable.

Where something is a regulatory requirement, I would state that plainly with the basis, and the discussion becomes about how to meet it rather than whether to.

Where it is a risk appetite question rather than a hard requirement, that is legitimately a business decision within governance — and compliance's role is ensuring it is informed and documented rather than blocking it.

I would also be honest about where compliance is creating unnecessary friction. Sometimes the business objection is correct and the process is inefficient, and acknowledging that builds the credibility needed when holding a genuine line.

Where disagreement persists, escalation through governance is the proper route, not attrition between individuals.

What I would avoid is winning through obstruction, which damages the relationship and encourages the business to work around compliance rather than through it.

75How do you assess whether the function is adequately resourced?

Through leading indicators rather than headcount ratios, since the right number depends entirely on volumes, complexity and automation.

The clearest signal is quality under load. If QA pass rates deteriorate while volumes are stable, the team is compensating by cutting corners, which means capacity is already exceeded.

Backlog trend rather than absolute size — a stable backlog is a capacity match; a growing one is a shortfall.

Ageing of high-risk cases specifically, since those should never be the ones waiting.

Overtime and turnover, which are early indicators that a team is sustaining output through effort rather than capacity.

And whether discretionary work happens at all — tuning analysis, coverage testing, training. When those stop because everyone is working alerts, the function has lost the ability to improve, which is a resourcing failure even if the queue looks under control.

76What is your view on outsourcing AML operations?

Execution can be outsourced; accountability cannot. The firm remains responsible for the quality of the work and for any failure, regardless of who performed it.

Where it works is high-volume, well-defined work with clear standards — first-level alert review, remediation populations, document collection. Where it works less well is judgement-heavy work requiring institutional knowledge.

The requirements are clear standards documented in enough detail to be applied consistently, quality oversight through sampling by the firm rather than self-reported metrics, and the ability to demonstrate the outsourced work meets the same standard as in-house.

The common failure is treating vendor-reported quality metrics as assurance. A provider grading its own work is not oversight.

I would also want the firm to retain enough in-house capability to assess the work meaningfully. Outsourcing to the point where nobody internally could evaluate quality is a significant concentration risk.

77What are the AML risks of a new business initiative?

The main risk is that the control environment does not move at the same speed as the business.

A new product, market or channel changes the risk profile, and each element of the programme needs to catch up — risk assessment, scenario coverage, data capture, customer due diligence requirements, and training.

The failure mode is launching before that work is complete, then discovering months later that activity has been unmonitored. Retrofitting is expensive and usually involves a retrospective review.

Specific risks depend on the initiative. New geography brings jurisdiction and sanctions exposure. New customer segments may not fit existing segmentation. New channels, particularly faster or more anonymous ones, change how quickly funds can move.

The governance answer is that AML should be involved at product approval rather than consulted after design. That is often resisted as slowing things down, but it is far faster than remediating post-launch.

78How do you keep the programme current?

Through structured horizon scanning rather than reacting to events.

Regulatory change monitoring, so requirements are tracked and assessed for impact before they take effect rather than after.

Typology monitoring — FATF reports, FIU publications, industry alerts — to test whether our detection reflects how criminals are currently operating rather than how they operated when the scenarios were written.

Enforcement actions against peers, which are the most practically useful source because they show exactly which failures are being penalised and at what cost.

Internal signals: what our own SARs are showing, where escalations are coming from, and whether new patterns are emerging.

And periodic reassessment of whether controls designed some years ago still address current risk. Programmes decay quietly — nothing breaks, but the environment moves and coverage narrows without anyone noticing.

79What do examiners focus on?

Control effectiveness rather than the existence of documentation. The question is not whether a policy exists but whether it works and whether anyone can demonstrate that.

In practice they sample cases and reassess them independently — reading the reasoning to see whether the conclusion is supported. Thin documentation fails immediately, because a decision that cannot be followed cannot be defended.

They test coverage against the firm's own risk assessment, looking for risks the firm has itself identified with no corresponding control.

They look at backlogs and ageing, because those indicate whether the programme is functioning at the volume it faces.

And they look hard at whether previously identified issues were remediated. A firm that knew about a gap and did not fix it is in a materially worse position than one that had not noticed.

Consistency across staff also gets tested — divergent decisions on similar facts suggest unclear standards.

80What are the most common enforcement findings?

They cluster around systemic weakness rather than individual cases, which is worth understanding because people expect enforcement to follow a missed transaction.

Inadequate scenario coverage — risks identified in the firm's own assessment with no detection logic behind them.

Untuned or unjustified thresholds, particularly where they were inherited and never tested below the line.

Alert backlogs, often substantial and long-standing, meaning activity went unreviewed.

Weak investigation documentation, where closures cannot be justified because the reasoning was never recorded.

Failure to remediate known deficiencies, which is consistently treated as the most serious because it demonstrates awareness without action.

And insufficient resourcing, usually evidenced through the backlog and quality data rather than headcount arguments.

The pattern is that regulators penalise programme failure, not bad luck on an individual case.

81Why does failure to remediate a known issue attract heavier penalties?

Because it changes the character of the conduct. A gap nobody identified is a control weakness; a gap identified and left unaddressed is a decision.

Regulators read that as the firm accepting a known risk to the financial system rather than failing to spot it, which moves the assessment from oversight toward recklessness.

It also undermines every other assurance the firm offers. If internal audit identified something and management closed it without fixing it, the regulator cannot rely on the firm's own governance.

The evidence is usually straightforward to establish — audit reports, risk registers and management minutes document exactly when the firm knew.

The practical implication is that identifying a problem creates an obligation. Firms sometimes worry that documenting a gap creates exposure, but the greater exposure comes from documenting it and not acting, which is the pattern enforcement notices describe repeatedly.

82How would you prepare for an examination?

By knowing our own weaknesses before the examiner does, because being surprised by a finding is far worse than presenting one with a plan.

That means reviewing file quality through internal sampling, checking the backlog position honestly, testing coverage against the risk assessment, and reviewing the status of open findings.

Where gaps exist, I would want a clear articulation of the issue, the remediation plan, the timeline and progress to date. Examiners respond very differently to a firm that says "we identified this, here is what we are doing" than to one that appears unaware.

I would ensure documentation is retrievable, since an inability to produce evidence is itself read as a control weakness.

And I would prepare staff on how to answer — accurately, within their knowledge, without speculating. Inconsistent answers across a team cause more damage than an acknowledged gap.

What I would not do is remediate cosmetically in the weeks before, which examiners recognise.

83How should staff handle examiner questions?

Answer accurately, within their own knowledge, and without speculating.

The most common error is trying to be helpful by answering beyond what they know — offering an opinion on why something is configured a certain way, or guessing at a process they do not own. Examiners cross-reference answers, and inconsistency between staff is read as a control weakness even where each answer was well intended.

So the correct response to a question outside their remit is to say so and identify who owns it. That is not evasive; it is accurate.

They should not volunteer opinions about whether controls are adequate, and equally should not conceal difficulties. Denying a backlog the examiner will find in the data damages credibility across the whole examination.

Preparation helps — not scripting, which is obvious, but making sure people understand their own scope and are comfortable saying they do not know.

84What is a monitorship?

An independent monitor imposed as part of a settlement or supervisory action, appointed to oversee remediation and report directly to the authority on the firm's progress.

They are intrusive. The monitor typically has broad access to systems, files, staff and management, and reports independently of the firm — so management cannot control the narrative reaching the regulator.

They are also lengthy, often running for years, and expensive, since the firm bears the cost of the monitor as well as the remediation.

The operational impact is significant beyond cost: senior time is consumed, and the firm effectively loses autonomy over its own compliance agenda for the duration.

Which is why avoiding one drives remediation urgency more than the financial penalty does. Firms will accept substantial fines more readily than a monitorship, because the fine is finite and the monitorship is not.

85What personal liability exists in AML?

More than people generally assume, and it has increased with accountability regimes.

Several jurisdictions provide for action against individuals — particularly MLROs and senior managers with designated responsibility — including fines, prohibition orders preventing them from holding regulated roles, and in serious cases criminal liability.

Accountability regimes such as the UK's senior managers framework make this concrete by assigning specific responsibilities to named individuals, so failure maps to a person rather than diffusing across the firm.

Below senior level, exposure is narrower but real. Failing to report where suspicion exists is an offence in many jurisdictions, as is tipping off, and both can attach to an individual regardless of institutional pressure.

The practical implication for an analyst is documentation. Where you are overruled, your assessment being on the record is what distinguishes your position from the decision that was taken.

86What lessons do you take from recent enforcement actions?

Three themes recur consistently enough to be worth naming.

Known gaps left unaddressed. Almost every significant case involves something the firm had already identified internally — in audit findings, risk registers, or management reporting — and did not fix.

Growth outpacing control investment. Firms expand into new markets, products or customer volumes while the compliance function stays the same size, and the gap widens quietly until something surfaces.

Monitoring coverage that never kept up. Scenarios designed for the business as it was, still running against a business that has changed substantially.

The underlying lesson is that enforcement rarely follows a single missed case. It follows a period during which the programme fell behind and nobody escalated it effectively — which is why the willingness to report bad news internally matters as much as technical control design.

87How do you evidence that a control is effective, not just present?

Through outcome data and testing rather than documentation.

For monitoring: escalation and SAR conversion by scenario, showing the logic produces findings; below-the-line testing showing thresholds are not leaving risk undetected; and coverage testing showing known patterns are caught.

For investigation quality: QA sampling results, and whether escalations are upheld.

For screening: injecting known test names and confirming they return.

For data: completeness reconciliation against source systems.

The common weakness is a control with a documented procedure, an owner and a review cycle, but no evidence it has ever detected anything or been tested. That satisfies a checklist and fails an examination.

The question I would want to answer for any control is: how would we know if this stopped working? If there is no answer, the control is not being evidenced regardless of how well documented it is.

88How do FATF mutual evaluations affect firms?

Indirectly but substantially. Mutual evaluations assess national regimes, not individual firms, but the consequences flow down.

A poor outcome typically drives regulatory tightening — new requirements, more intensive supervision, and pressure on regulators to demonstrate enforcement activity. Firms experience that as changed expectations and heavier scrutiny.

Where a jurisdiction is grey-listed, the effect is more direct: institutions elsewhere apply enhanced due diligence to counterparties there, correspondent relationships come under pressure, and cross-border business becomes more difficult and expensive.

For a firm operating in an evaluated jurisdiction, it is worth reading the evaluation itself. It identifies specific national weaknesses, and those are precisely the areas where supervisory attention will concentrate afterwards.

It also affects country risk ratings, since listing status feeds directly into geographic risk assessment and therefore into due diligence requirements.

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

Contain first. I would confirm the scope — which scenario, which data, from what date — and get the feed restored, because until it is fixed the gap continues.

Then assess exposure. Six months of transactions passed unmonitored against that scenario, so I would establish what population that covers and what risk the scenario was designed to detect. A high-value structuring rule going dark is materially different from a peripheral one.

A retrospective review over the affected period is the standard response — running the logic against historical data to identify what would have alerted, and investigating those.

I would escalate to compliance leadership immediately rather than treating it as a technical issue, because this is a reportable control failure.

And I would ask why it went unnoticed for six months. The absence of alerts should itself have been monitored, and that missing detective control is the deeper finding — because whatever caused this scenario to fail silently could affect others.

90Alert volumes have tripled after a tuning change and the team cannot cope. How do you respond?

I would not revert it unilaterally, and I would not let alerts age unreviewed while it is debated — both create risk.

First, protect coverage: triage by risk so the highest-exposure alerts are worked while the volume issue is resolved. Letting everything age uniformly means genuinely high-risk cases sit behind noise.

Then diagnose. Sampling a batch of the new alerts answers the key question quickly — are these detecting something previously missed, or is the change misfiring on a segment where the threshold no longer fits?

That determines the response entirely. If detection genuinely improved, the answer is resourcing, not reverting. If it is miscalibration, the change needs adjusting through governance with the sampling evidence attached.

Meanwhile I would report the backlog position transparently rather than absorbing it, because a reported backlog with a plan is manageable and a concealed one becomes a finding.

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

I would complete the investigation on its merits and document the request.

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

I would respond professionally rather than confrontationally — that I will complete the review properly, and if the activity is explained it will close on that basis. That is not obstruction; it is the same standard applied to everyone.

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

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

If they have genuine information about the customer, the right route is providing it, not instructing the outcome — and I would say that directly.

92You identify a pattern across twelve unrelated customers suggesting an organised network. What now?

I would escalate it as a single linked case rather than twelve separate ones, because the connection is the finding and filing them individually loses it entirely.

First I would map the linkage properly — shared counterparties, common beneficiaries, timing patterns, onboarding period, shared identifiers such as addresses, phones or devices. The strongest link is usually a common beneficiary where separate flows converge.

Then aggregate the value, since individually modest amounts across twelve accounts can total substantially and the aggregate is what makes the case significant.

I would brief the MLRO on the network as a whole, because that shapes the reporting approach and may warrant a single comprehensive report rather than twelve thin ones.

And I would flag it for scenario review. If a coordinated pattern across twelve accounts evaded detection at the individual level, our logic is not catching network behaviour — and that is a coverage gap worth raising beyond this case.

93An internal audit finds 30 percent of your team's closed alerts lack adequate documentation. How do you respond?

I would accept the finding and treat it as systemic, because a failure rate that high is not thirty percent of individuals being careless.

The diagnostic questions are: is the documentation standard clearly defined and understood, is there time pressure making proper write-ups impractical, was training adequate, and does the case management system make good documentation difficult?

Time pressure is the most common cause — analysts asked to close volumes that do not permit proper recording will record less.

Then remediation. Files closed without adequate documentation cannot be demonstrated as sound, so the affected population likely needs reviewing, which is expensive and is the real cost of the finding.

On prevention: clarify the standard with worked examples, adjust volume expectations if that is the driver, and build documentation quality into routine QA rather than periodic audit.

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

94The business wants to launch a product in a high-risk market in six weeks. Compliance readiness is not there. What do you say?

I would set out precisely what is missing and what the exposure is, rather than simply objecting.

Concretely: no risk assessment for the market or product, no scenario coverage for the associated typologies, transaction data that may not be captured in a form monitoring can use, and no resourcing allocated. Each of those is a specific gap with a specific consequence.

The exposure argument is the one that lands — launching unmonitored means activity flows with no detection, and if that surfaces later it means a retrospective review, potential reporting failures, and a regulatory finding that the firm launched knowing controls were absent.

Then I would offer a path rather than a block: a phased launch with restricted scope, volume caps, or manual review as a compensating control while proper coverage is built.

If the business proceeded regardless, I would ensure the risk acceptance is documented at the appropriate level with the gaps stated explicitly.

95You inherit a function with a 4,000-alert backlog. What are your first three actions?

First, triage by risk. Chronological processing means high-risk alerts from this week sit behind low-risk ones from six months ago. I would segment by customer risk, value, sanctions adjacency and prior escalations, and work the highest exposure immediately — that protects the position while everything else is sorted out.

Second, establish the cause, because the remedies are mutually exclusive. Excessive noise from poor tuning is not solved by adding analysts. Genuine capacity shortfall is not solved by tuning. A data issue generating spurious alerts is solved by neither. Sampling the backlog tells you which within a day or two.

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

That third action matters most. Backlogs become findings not because they exist but because they were concealed. A reported backlog with a credible plan is a manageable issue; a hidden one discovered in examination is not.

96How do you build and develop an AML team?

By teaching reasoning rather than process, because process can be documented but judgement has to be developed.

Practically that means reviewing real cases together and discussing why a conclusion was reached, not just whether it was right. Analysts who understand the reasoning behind a decision can apply it to a case they have not seen before; those who learned the procedure cannot.

Specific feedback on files rather than general encouragement — pointing at what was missing in a particular narrative is worth more than a quality score.

Letting people work through complexity with support rather than taking the case off them, which is faster in the moment and develops nobody.

And creating conditions where raising concerns is safe, since a team that escalates freely is more valuable than one that is technically strong but silent.

I would describe something I have actually done here rather than a philosophy, because the specifics are what make it credible.

97Tell me about a time you changed your mind on a case.

This needs a real example, and the value is in the mechanism rather than the outcome.

The structure that works: what you initially concluded and why that was reasonable on the information available, what new evidence emerged, how it changed the picture, and what you did about it.

The strongest versions involve reversing toward escalation — concluding something was explained, then finding evidence that undermined the explanation. That demonstrates you follow evidence rather than defending a position.

Reversals in the other direction work too: escalating something, then finding a legitimate explanation that resolved it. That shows you do not treat escalation as a one-way ratchet.

What interviewers are testing is intellectual honesty under pressure. Analysts who cannot recall ever changing their mind are usually either inexperienced or not examining their own reasoning.

98How do you balance detection effectiveness against operational cost?

By measuring where detection actually comes from and directing effort there, rather than treating every control as equally valuable.

Scenario-level outcome data is the tool. If two scenarios generate sixty percent of alerts and produce almost no escalations, while a third generates few alerts and most of the escalations, that is where tuning and resourcing decisions should start.

The efficiency gain should come from better targeting — improved segmentation, refined logic, better customer data — rather than from raising thresholds or reducing review depth. Those reduce cost and detection together.

I would also count the cost of poor quality honestly. Rushed closures do not save money; they defer work into remediation, which is far more expensive and comes with regulatory consequences.

And there is a floor. Some detection is required regardless of cost-benefit, because the obligation is not discretionary and a control cannot be dropped because it is inconvenient.

99Do you want to become an MLRO?

Answer honestly — both answers are respectable, and the wrong move is claiming ambition you do not have or hiding ambition you do.

If yes, demonstrate you understand what it carries: personal regulatory accountability, ownership of the reporting decision, being the point of contact for the FIU and the regulator, and the position of having to hold a line against senior management when necessary. Showing you understand the accountability rather than just the seniority is what makes the answer credible.

If no, be clear about what you want instead — deep specialism in a typology, investigations leadership, financial crime advisory, or systems and tuning ownership. A clear alternative direction reads as considered.

What lands badly is vagueness. "Maybe eventually" tells them nothing and suggests you have not thought about your own trajectory.

100What questions do you have for us?

Always have three or four ready, and make them operational rather than generic.

Good ones for a senior AML role: what does scenario coverage look like relative to the risk assessment, and how is tuning governed? What is the current backlog and ageing position? How are escalation disagreements between analysts and the MLRO resolved? What did the last audit or examination find, and where is remediation? How do compliance and the business resolve disputes in practice?

Those questions do two things. They tell you whether the function is genuinely supported or under-resourced, which matters for whether you want the job. And they demonstrate you think at control level rather than case level.

Asking about the backlog in particular signals experience — anyone who has worked in a stretched function knows that is the question that reveals the reality of the role.