Fraud investigation copilot

When an alert fires, the copilot gathers context with read-only tools (transactions, device and login history, customer profile, related accounts, prior cases), summarises the pattern with evidence links, suggests typologies and next checks, drafts a case narrative and, where relevant, a SAR draft. The analyst decides the outcome; their decision and edits are logged for audit and learning.

Every statement links to source records (transaction IDs, timestamps), numbers are computed by code not the model, uncertainty is stated, and analysts can expand any claim to the raw data.

Keep detection models and rules separate from the copilot, never let the copilot close alerts automatically, measure analyst decisions with and without the copilot, and review samples of closed cases.

The agent's job is to assemble evidence; decisions with legal and customer impact, such as blocking an account or filing a report, belong to accountable analysts. Read-only tools also limit damage if the agent is wrong or manipulated, and make regulators more comfortable.

Use past cases with known outcomes. Measure whether the summary includes the key evidence, whether its recommendation matches the analyst's decision, how often it misses or invents facts, and how much time it saves. Track drift as fraud patterns change.

Core banking transactions, card authorisations, digital banking logs (devices, IPs, sessions), KYC and customer profile data, sanctions and PEP screening results, previous alerts and cases, and network links between accounts.

Build a graph of accounts linked by transfers, shared devices, phone numbers or addresses, and look for patterns like many inbound transfers quickly moved out; graph queries and analytics surface clusters for the analyst.

Run models in approved environments, restrict data to need-to-know, mask sensitive fields where possible, log all access, keep data in required jurisdictions, and follow model risk management guidelines.

Measure time per case, decision accuracy against quality assurance reviews, completeness of evidence gathered, analyst satisfaction, and consistency of SAR narratives, comparing with a control group.

Banks must validate, document and monitor models used in decisions (guidance like SR 11-7 or RBI directions). Even assistive AI needs documented purpose, limitations, testing and ongoing monitoring.

Follow the regulator's structure (who, what, when, where, why, how), use only facts gathered by tools with references, avoid speculation, and require the analyst to review and own the final filing.

Run data-gathering tools in parallel, cache customer context per case, precompute common aggregates, and stream the summary while details load.

Rules catch known, explainable patterns and regulatory thresholds; machine-learning models score unusual behaviour in real time; the copilot helps analysts investigate the alerts both produce by gathering evidence and drafting narratives. Analyst outcomes feed back to tune rules and retrain models.

Score each alert by risk, amount at stake, customer vulnerability and age, group related alerts into one case, put the highest combined priority first, and track time-to-decision against service targets so high-risk cases are never left waiting.

A Suspicious Activity Report (in India, a Suspicious Transaction Report to FIU-IND) that a bank must file with its financial intelligence unit when it suspects money laundering or fraud. It needs a clear factual narrative, which the agent can draft for the analyst to review.

The copilot should never move money, freeze accounts or close cases itself; those actions carry legal and customer impact and require authorised humans with proper controls.

Capture decisions, corrections to summaries and useful or missing evidence, feed them into evaluation datasets, and use confirmed outcomes to improve detection models separately.

Link suggested typologies (account takeover, mule activity, structuring) to internal playbooks with indicators and next steps, so the copilot also teaches.

Treat free-text fields like payment references as untrusted, never follow instructions found in them, and restrict tools so injected text cannot trigger actions.

Splitting transactions into amounts just below reporting thresholds to avoid detection; the copilot can highlight repeated near-threshold deposits across accounts and branches.

Real-time decisions use fast scoring models and rules within milliseconds at authorisation; the copilot supports the slower investigation and customer contact afterwards.

Render a link graph of accounts, devices and counterparties with edge labels (amount, date), letting analysts expand nodes and open details.

Use templates for summaries and narratives, standard evidence checklists per typology, and evaluation of consistency on sample cases.

Compare each session with the customer's normal devices, locations, typing and navigation patterns, flag changes like a new device plus a password reset plus a new payee, and step up authentication before high-risk actions rather than after money moves.

Look for scam signals such as a first payment to a new payee, unusual amounts, urgency in the payment reference, and remote-access software on the device. Warn the customer with specific scam messages and offer a delay or call-back for high-risk payments.

Segment thresholds by customer type, add context features such as known travel or salary days, review the top false-positive patterns with analysts, test changes on historical data, and watch fraud loss rates alongside alert volume after each change.

Use industry schemes or consortium databases that exchange hashed or tokenised indicators such as mule account numbers and device fingerprints under legal agreements, so banks learn from each other without exposing customer data.

Every tool query, data accessed, summary generated, model version, and the analyst's decision with timestamp, retained per regulatory requirements.

Checks of customers and counterparties against politically exposed persons and sanctions lists; matches raise risk and may require enhanced due diligence or blocking.

Pilot with a team on one alert type, compare metrics with a control group, gather feedback, validate with model risk teams, then expand.

Make final decisions, contact customers, close alerts, freeze accounts, or file reports without analyst approval.

Load typologies and red-flag guidance as versioned documents from regulators and internal financial-crime teams, review and update them on a schedule, and show the version and date with each suggestion.

1. AThe customer
2. BThe detection model alone
3. CThe analystCorrect answer
4. DThe copilot

Why: The copilot only assists.

1. AThe model's estimate
2. BGuesswork
3. CThe customer
4. DCode computing them from recordsCorrect answer

Why: Language models often miscount.

1. AReads are faster
2. BWrites are impossible
3. CTo save tokens
4. DActions with legal impact need authorised humansCorrect answer

Why: No moving money or freezing accounts.

1. AEmail customers directly
2. BFreeze accounts
3. CRead transaction, device and KYC dataCorrect answer
4. DReverse payments

Why: Read-only access lets it investigate without taking action on accounts.

1. ALogo colours
2. BEmail signatures only
3. CGraphs of transfers and shared identifiersCorrect answer
4. DFont usage

Why: Look for in-and-out patterns.

1. ASpeculation
2. BModel reasoning only
3. CCustomer opinions
4. DOnly facts with referencesCorrect answer

Why: The analyst owns the filing.

1. AOpening accounts
2. BSplitting amounts below reporting thresholdsCorrect answer
3. CFormatting reports
4. DBuilding databases

Why: A classic evasion pattern.

1. AGDPR Article 1
2. BISO 9001
3. CSR 11-7Correct answer
4. DPCI DSS

Why: Validation and monitoring of models.

1. AUntrusted inputCorrect answer
2. BInstructions to follow
3. CVerified facts
4. DSecret keys

Why: It may contain injection attempts.

1. ATime per case and decision accuracy vs. controlCorrect answer
2. BNumber of words
3. CTokens used
4. DServer uptime only

Why: Compare with a control group.

1. AReplaces rules and models
2. BSets interest rates
3. CHelps analysts investigate alertsCorrect answer
4. DBlocks payments on its own

Why: Detection stays with rules and models; the copilot speeds investigation.

1. AIgnored
2. BClosed automatically
3. CGrouped into one caseCorrect answer
4. DWorked separately by different analysts

Why: One case gives the full picture once.

1. AEach claim linked to its source recordCorrect answer
2. BA confident tone
3. CNo numbers
4. DLong paragraphs

Why: Links let the analyst verify every statement quickly.

1. ALabelled data to evaluate and improve the agentCorrect answer
2. BPublic reports
3. CMarketing material
4. DDeleted after closing

Why: They are ground truth for measuring the agent's accuracy over time.

1. ADaily batches
2. BFast scoring models within millisecondsCorrect answer
3. CThe investigation copilot
4. DEmail review

Why: The copilot works afterwards.

1. AAlertsCorrect answer
2. BBrowser tabs
3. CLog files
4. DDraft notes

Why: Closing alerts is an analyst decision.

1. APayment gateways
2. BPhone models
3. CPolitically exposed personsCorrect answer
4. DPassword strength

Why: Raises risk and due diligence.

1. AIt is discarded
2. BIt builds evaluation sets and improves detectionCorrect answer
3. CIt replaces audits
4. DIt trains the model live

Why: Confirmed outcomes matter.

1. AA link graph of accounts and devicesCorrect answer
2. BA pie chart
3. CA word cloud
4. DA timeline only

Why: Expand nodes for details.

1. ANo structure
2. BTemplates and evidence checklistsCorrect answer
3. CHigher temperature
4. DDifferent prompts per analyst

Why: Consistency across analysts.

1. ANeed more analysts
2. BReduce waiting time for contextCorrect answer
3. CIncrease errors
4. DAre forbidden

Why: Gather data concurrently.

1. AEmailed
2. BLogged in plain text
3. CMasked where possible with need-to-know accessCorrect answer
4. DShared widely

Why: Privacy and regulation.

1. AA normal salary payment
2. BA software update
3. CA loan application
4. DAccount takeoverCorrect answer

Why: The combination is a classic takeover pattern.

1. AA specific scam warning and an optional delayCorrect answer
2. BSilently approving it
3. CClosing the account
4. DEmailing a generic newsletter

Why: Customers authorise these payments, so warnings must persuade.

1. AA single analyst's opinion
2. BHistorical data before releaseCorrect answer
3. CLive customers only
4. DNo data

Why: Back-testing shows the effect on alerts and losses.

1. AUnencrypted spreadsheets
2. BCustomer emails
3. CConsortium schemes with hashed or tokenised dataCorrect answer
4. DPublic social media posts

Why: Indicators help without exposing customer data.

1. AOnly errors
2. BNothing
3. CQueries, data accessed, outputs and decisionsCorrect answer
4. DOnly logins

Why: Retained per regulation.

1. AOnly on weekends
2. BPilot one alert type with a control groupCorrect answer
3. CAll alert types at once
4. DWithout validation

Why: Validate before expanding.

1. ANothing
2. BInternal playbooksCorrect answer
3. CSocial media
4. DRandom articles

Why: The copilot also teaches.

1. ALogins
2. BRepeated questions within a caseCorrect answer
3. CModel training
4. DPayments

Why: Fewer repeated data calls.

1. AAuthorised staffCorrect answer
2. BThe copilot automatically
3. CThe model provider
4. DNobody

Why: Customer contact is a human action.

1. AThe model's weights
2. BIts version and dateCorrect answer
3. CNo source
4. DThe analyst's password

Why: Analysts must know how current the guidance is.