17.2 Working With Law Enforcement, Banking Partners, Regulators, and Other Third Parties

CAFCA sub-topic 4.5 asks how to work and communicate with third parties, such as law enforcement, banking partners and regulators. These relationships decide whether intelligence turns into action, whether a partner bank keeps confidence in the programme, and whether a supervisor sees the firm as cooperative or evasive.

Law enforcement

Inbound requests. Run all law enforcement contact through a single point of contact, such as a law enforcement liaison or subpoena response team, with a logged intake.

1. Verify the requester. Confirm identity and authority through the agency's official switchboard or portal, not the phone number or email in the request. Fraudsters impersonate police and agencies, including with fake "emergency" requests.
2. Confirm the legal basis and scope. Is it a compulsory order, a voluntary request, a 314(a) search, or a request for SAR supporting documentation? (Chapter 17 lists the types.)
3. Apply privacy and confidentiality rules. Disclose what the law requires or permits. Voluntary disclosure must have a lawful basis under privacy and financial privacy laws.
4. Meet deadlines and produce accurately. Quality-check productions, log what was sent, and use secure transfer.
5. Respect non-disclosure. Many requests carry confidentiality terms. Do not tell the customer.
6. Review the relationship. A request is not itself proof of wrongdoing. US examiners say a subpoena alone should not automatically trigger a SAR, but it should prompt a risk review of the customer.

Proactive engagement. Firms add value through public-private partnerships. Examples include the UK's Joint Money Laundering Intelligence Taskforce (JMLIT, 2015), FinCEN Exchange (2017) in the US, and Singapore's AML/CFT Industry Partnership (ACIP, 2017). They also use fraud recovery channels such as the FBI's Internet Crime Complaint Center and FinCEN's Rapid Response Program for urgent international wire recalls.

Banking partners

In BaaS, sponsorship and correspondent models, communication with the bank is set by contract (Chapter 6):

• Referral protocols: what the FinTech must escalate to the bank (unusual activity, potential SAR matters, sanctions hits, law enforcement requests), within what time, and in what format.
• Information sharing: FinCEN-registered US institutions can share information about possible money laundering or terrorist financing under section 314(b), with a safe harbour. Joint SARs are possible between institutions involved in the same transaction. A SAR itself, and information that would reveal it, may be shared only where the rules expressly allow it.
• Incident notification: data breaches, control failures, outages and regulatory contact, as the agreement requires.
• Consistent customer messaging: agree who tells the customer what, so that the bank and the FinTech do not contradict each other or tip off.

Regulators

• Candour and cooperation. In the UK, FCA Principle 11 requires firms to deal with regulators openly and cooperatively and to tell the FCA about anything it would reasonably expect to hear about. Other supervisors expect the same in substance.
• Timely self-reporting of material breaches, as rules and licence conditions require.
• Examination management: one coordinator, accurate document productions, management responses to findings, and remediation plans with realistic dates and owners. Never overpromise dates you cannot meet.
• Consistency: the information given to the regulator, the partner bank and the board must tell the same story.

Other third parties

• Card networks and payment schemes have rules on fraud reporting, high-risk merchants and data security.
• Other FinTechs and VASPs: share information through lawful channels, such as 314(b), Travel Rule messaging and industry fraud-sharing schemes. In the UK, the Economic Crime and Corporate Transparency Act 2023 removed civil liability for breach of confidence for certain sharing between regulated firms to prevent economic crime.
• Vendors: incident notification, audit cooperation and data handling under contract (Chapter 18).

Communication principles that apply to every party

Realistic exam scenario

A support agent receives an email from a Gmail address signed "Special Agent, FBI". It asks for full account details and recent IP logs for three customers "within the hour" for an emergency. The agent should not respond with data. The request goes to the law enforcement liaison, which verifies it through the FBI's official channels. Production follows only if the request is genuine and lawful. If the request proves fake, it may itself indicate an attempt at account takeover or data theft and should be escalated to security.

Common exam traps

• Sending data in reply to an unverified request.
• Telling the customer about a law enforcement request.
• Over-sharing with the partner bank by forwarding SAR copies where the rules do not permit it.
• Hiding problems from the regulator until the next examination.