Information Sharing vs. Data Privacy

Financial crime is a network problem, but banks often see only fragments of the network. One bank sees a victim sending money. Another sees a newly opened beneficiary account receiving funds from many unrelated people. A payment service provider sees rapid onward transfers. A telecom or digital platform may see the social-engineering contact that preceded the payment. A financial intelligence unit may hold reports from several institutions that, when combined, reveal a coordinated criminal operation. If every participant works only from its own fragment, the criminal network can look like a set of ordinary customers and ordinary payments.

That creates the central tension of information sharing. Banks need enough information to detect, investigate and disrupt financial crime, but customer and case information is not an unrestricted common resource. Personal data, confidential banking information, suspicious-activity reports, law-enforcement material and intelligence received from public authorities can all be subject to different legal, regulatory, contractual and security restrictions. The difficult question is therefore not simply “may we share?” or “does privacy stop us?”. A professional control asks a more precise sequence of questions: what is the financial-crime purpose, who is the recipient, which legal gateway applies, what information is actually necessary, what special confidentiality rules attach to it, what cross-border or security controls are required, and what evidence must be retained to prove the decision later?

A useful mental model is: share the minimum useful truth through the right gateway, to the right recipient, for the right purpose, with an auditable trail. This avoids two equally dangerous extremes. The first is over-sharing: sending entire customer files, investigation notes or sensitive personal information because “AML is important”. The second is under-sharing: refusing a lawful and necessary disclosure because “GDPR” or “privacy” is used as a generic stop sign without identifying the actual rule. Neither approach is defensible. Effective financial-crime control and data protection are meant to be designed together.

Information-sharing operating model showing different sharing lanes passing through legal, privacy, secrecy and security controls

Why the issue matters in a real bank

The harm from weak sharing is easy to underestimate because it often appears as a series of local control failures rather than one dramatic event. A fraud team may identify a mule account but not pass the intelligence to AML investigators. A correspondent-banking team may receive a request for information that suggests a customer relationship is being misused, but the information may never reach the customer-risk owner. A group subsidiary may identify a beneficial owner of concern while another subsidiary continues transacting because the information cannot be located or the legal pathway for sharing was never designed. A bank may file a suspicious transaction report but fail to use the underlying facts to strengthen monitoring, subject to applicable confidentiality rules. Criminals benefit from the gaps between teams, legal entities, institutions and jurisdictions.

Weak privacy design creates a different set of harms. Excessive sharing can expose innocent customers, create false associations, compromise investigations, trigger regulatory breaches, increase cyber risk and undermine trust. A suspicion is not a conviction. An alert is not proof of crime. An adverse-media hit may refer to the wrong person. A shared label such as “mule”, “sanctioned”, “fraudster” or “high risk” can cause significant customer impact if the underlying evidence, confidence and context are not preserved. Information sharing must therefore transmit enough meaning for the recipient to use the information responsibly rather than passing an unexplained risk flag downstream.

Banks also need to distinguish data access from data sharing. An employee within one legal entity viewing a customer record under an approved role is different from sending that record to another group company. A group-wide case platform can create cross-entity access even if no one sends an email. A central data lake can replicate information across borders automatically. A vendor-hosted analytics service can process customer data in another jurisdiction. A public-private partnership may allow controlled exchange among participants under a specific framework. Each arrangement creates a different legal and technical pattern even when the business describes all of them casually as “sharing”.

The control is therefore architectural as well as legal. A policy may correctly say that sharing requires a lawful basis, but if the case-management system has no recipient classification, no data-minimisation step and no audit record of what left the bank, staff are forced to improvise. Conversely, a beautifully engineered secure portal does not make a disclosure lawful if the bank has not identified an applicable authority. Good design joins legal analysis, financial-crime purpose, data governance, identity and access, workflow, security, records management and operational ownership.

Start with the sharing lane

Before deciding what can be shared, identify the lane through which the information will move. The same fact can be treated differently depending on whether it stays within one legal entity, moves across a banking group, goes to another financial institution, is sent to an FIU or law-enforcement authority, or crosses a national border.

Within one legal entity, information sharing often means controlled internal access. Fraud, AML, sanctions, KYC, payments and customer-service teams may need to exchange facts about the same customer or transaction. Even here, “internal” does not mean “everyone may see everything”. Role-based access, need-to-know restrictions, sensitive-case controls and segregation may apply. Insider investigations, employee cases, sanctions escalations, politically exposed persons, law-enforcement requests and SAR/STR material can need additional restrictions.

Within a banking group, the business argument for sharing can be strong because criminals move across products, branches and legal entities. FATF Recommendation 18 and related guidance support group-wide programmes and information flows needed for AML/CFT controls, while national or regional law determines what is permitted in practice. A group should not assume that the parent company’s legal basis automatically authorises every subsidiary to export every customer record. The design needs a jurisdiction map, entity scope, data categories, purpose, recipient roles and restrictions on onward use.

Between financial institutions, sharing is more constrained and usually depends on a specific framework. In the United States, for example, Section 314(b) provides a voluntary safe-harbour framework for eligible participating financial institutions and associations to share information for specified purposes. FinCEN refreshed its 314(b) fact sheet on 12 June 2026 and clarified the use of the framework in relation to suspected fraud. That is a US-specific mechanism, not a global permission. Other jurisdictions have different statutory gateways, private-sector partnerships or no equivalent arrangement.

Public-private partnerships create another lane. FATF’s July 2026 global report on information sharing describes a growing landscape of partnerships that combine public and private information to improve detection and disruption of illicit finance. FATF identified at least 84 public-private partnerships globally in that work. The important lesson is not the number; it is the design principle. Sustainable partnerships require a robust legal basis, clear governance, defined purposes and technology that supports controlled, actionable exchange. A partnership is not an informal chat group with a compliance label.

Sharing with an FIU, regulator or law-enforcement authority may be mandatory, permitted on request, voluntarily authorised or prohibited outside a formal channel, depending on the information and jurisdiction. A production order, subpoena, FIU request, supervisory request and voluntary intelligence disclosure are not interchangeable. The bank needs to validate the authority, scope, deadline, recipient identity and confidentiality requirements. It also needs a process for over-broad or unclear requests rather than forcing operations staff to make legal judgements under time pressure.

Cross-border sharing adds another layer. Data-protection transfer restrictions, banking secrecy, localisation rules, blocking statutes, state-secrecy laws, professional confidentiality and local FIU rules can all matter. The fact that the receiving entity belongs to the same group does not remove the need to assess the transfer. Likewise, a technically global cloud platform can create cross-border processing even where the business user believes information has stayed “inside the bank”.

Global standards and local law

FATF treats effective information sharing as an important part of AML/CFT effectiveness. Its standards and guidance address group-wide information, financial-institution secrecy, suspicious-transaction reporting, FIUs and international cooperation. One important principle in Recommendation 9 is that financial-institution secrecy laws should not inhibit implementation of the FATF Recommendations. That principle should not be misread as a global override of privacy or confidentiality law. FATF sets international standards; domestic and regional law determines the legal mechanism through which an institution complies.

Recommendation 18 is especially relevant to financial groups. Group-wide AML/CFT programmes need policies and procedures for sharing information required for customer due diligence and risk management, with safeguards on confidentiality and use. Recommendation 20 concerns reporting suspicious transactions to the FIU. Recommendation 21 addresses protection for good-faith reporting and restrictions on tipping off. Recommendation 29 sets the role of FIUs, while Recommendation 40 addresses international cooperation. Those standards create a connected framework: financial intelligence must move, but it must move through controlled channels that preserve confidentiality and legal safeguards.

The tension becomes clearest around suspicious-activity reporting. In many jurisdictions, the SAR or STR itself, and information that would reveal that such a report has been or will be filed, receives special protection. That is not the same thing as saying that every underlying fact in an investigation becomes unshareable. A payment, customer identifier, account number, device signal or business explanation existed independently of the report. Whether those underlying facts can be shared depends on the applicable framework and purpose. A good system therefore distinguishes case facts, investigator analysis, suspicion decisions, SAR/STR content, SAR/STR existence, and FIU or law-enforcement intelligence instead of storing everything under one undifferentiated “case notes” field.

FATF has also clarified that tipping-off rules should not frustrate appropriate group information sharing where the standards contemplate it. Again, the implementation is local. The operational requirement is to encode the difference into policy and workflow so that an analyst is not expected to remember complex jurisdictional distinctions every time a case crosses a border.

The European Union provides a useful example of a detailed statutory framework. Regulation (EU) 2024/1624 includes Article 75 on information-sharing partnerships. It allows specified sharing among partnership members where strictly necessary for relevant AML/CFT obligations and subject to safeguards, participant responsibilities, supervisory verification and a data-protection impact assessment. The article also limits the categories and purposes of information that can be exchanged. Article 76 addresses processing of personal data for AML/CFT, including sensitive categories and safeguards. These are EU rules with their own scope and application dates; they should never be presented as a universal model. They are useful educationally because they show what mature control design looks like when the law explicitly connects AML information sharing with data-protection obligations.

In the United Kingdom, data-protection law and ICO guidance similarly show that privacy law does not prohibit all fraud-prevention sharing. An organisation still needs a lawful basis and, where criminal-offence data is involved, the additional conditions and safeguards required by UK law. The precise lawful basis is context-dependent. A bank should not build one global field called consent=true and assume that consent is always the correct basis. In regulated financial crime work, legal obligations, public-interest conditions, legitimate interests or other statutory gateways may be relevant depending on the jurisdiction, recipient and purpose.

Privacy principles translated into bank controls

Privacy principles become useful only when translated into operational questions. Purpose limitation means the bank can explain why the information is being used and whether the recipient’s use is compatible with that purpose. A dataset collected for onboarding does not automatically become a general intelligence product. If a public-private partnership is designed to identify mule networks, the permitted use and onward sharing should be defined before the first case is exchanged.

Lawfulness means the bank identifies the actual gateway rather than using “AML” as the gateway. The evidence may be a statutory obligation, regulatory power, safe harbour, contractual framework supported by law, legitimate-interest assessment, FIU authority, court order or another recognised basis. The label and approval owner should be recorded. Where the gateway is uncertain, the safe action is escalation, not imaginative interpretation.

Necessity and data minimisation mean selecting the information required to achieve the legitimate financial-crime objective. Suppose another institution asks whether a beneficiary account is linked to a shared mule investigation. It may be unnecessary to send the full KYC file, copies of identity documents, unrelated account balances and every transaction ever made. A targeted response with identifiers, relevant time period, transaction references and contextual risk information may be sufficient. Minimisation protects customers and also improves investigative quality by reducing noise.

Accuracy means the recipient can distinguish verified facts from allegations, analytical assessments and unresolved matches. “Customer is a fraudster” is a poor data object. “Account received six credits currently linked to reported scam cases; investigation remains open” preserves the evidential status. Shared data should carry dates, source, confidence and effective time where those fields matter. If the source information is later corrected, the operating model should define whether and how recipients are notified.

Storage limitation and retention require a reasoned lifecycle. The sharing record may need to be kept long enough to demonstrate compliance, support an investigation or meet legal retention rules, but not indefinitely by default. The underlying shared payload and the audit record may have different retention periods. Legal holds, ongoing investigations and FIU instructions can change the answer. Retention rules should be data-class and jurisdiction aware rather than one universal deletion date.

Security and confidentiality cover more than encryption. The bank should verify recipient identity, control access, restrict download or onward sharing where appropriate, use approved channels, monitor anomalous access and maintain incident-response procedures. A lawful disclosure sent to the wrong external address is still a serious failure. The same is true when a secure portal allows a user to search information beyond the partnership purpose.

Accountability means someone can reconstruct the decision. Months later, an auditor should be able to answer: who requested the information, which customer or case was involved, what purpose was recorded, what authority applied, which fields were shared, who approved the disclosure, which channel was used, who received it, what restrictions applied and how long the record should remain.

Information classes: not all financial-crime data is equal

Banks often create risk by treating “financial-crime data” as one category. A more useful classification separates information by sensitivity and legal treatment.

Basic customer and transaction facts include names, identifiers, account details, payment references, dates, amounts and counterparties. These may already be sensitive personal or confidential banking data, but they are conceptually different from an investigator’s suspicion.

CDD and KYC information can include identity documents, addresses, beneficial ownership, occupation, source of wealth, source of funds, expected activity and risk ratings. Some fields may contain special-category, criminal-offence or similarly protected data depending on the jurisdiction.

Monitoring and fraud intelligence can include alerts, typology matches, device links, mule indicators, graph connections and behavioural risk signals. These should preserve their status as indicators rather than facts of criminal conduct unless verified.

Investigation material includes hypotheses, analyst notes, requests for information, customer explanations and conclusions. Free-text notes are particularly risky because they can combine facts, speculation and references to protected reports in one paragraph. Structured fields and disciplined narrative make controlled sharing much easier.

SAR/STR-related information needs explicit handling. The report, its existence, filing decision, FIU acknowledgement and associated protected communications may have stricter rules than the underlying business facts. Systems should label these categories so an export tool can prevent accidental inclusion.

Public-authority intelligence may be received under conditions that prohibit onward dissemination. An FIU or law-enforcement agency may provide information for a specific purpose. The bank should record origin, restrictions and handling instructions at ingestion rather than relying on a user to remember them later.

This classification should drive entitlements and disclosure behaviour. A case manager might be allowed to share verified transaction facts with an approved peer institution but prohibited from exporting the SAR tab. A group investigator might be able to see a risk indicator but not the identity of a confidential source. A disclosure service can use policy rules to block, mask or require additional approval for certain fields.

A practical disclosure decision

A sharing request should move through a repeatable decision rather than an email chain of opinions. The starting point is the purpose. What financial-crime risk is being addressed? Which customer, transaction, network or investigation creates the need? A vague purpose such as “for compliance” is too broad.

Next identify the recipient. Is it another team in the same legal entity, another group company, a bank participating in an approved partnership, a correspondent, an FIU, a regulator, law enforcement or a service provider? Verify the recipient’s identity and role. A domain name or job title is not always sufficient for sensitive disclosures.

Then identify the legal and policy gateway. The workflow should present approved gateways relevant to that entity and jurisdiction, not a global free-text field. Some gateways may permit only defined data categories or purposes. Some may require a notice, participant registration, FIU agreement, data-protection impact assessment, legal review or supervisory condition.

The fourth step is minimisation. Which fields are necessary? Which time period? Can identity documents be excluded? Can free text be replaced with structured facts? Can an identifier be tokenised or pseudonymised until the recipient has a legitimate need for full identity? Minimisation is not merely a privacy exercise; it forces the investigation team to express what evidence actually matters.

The fifth step checks confidentiality and tipping-off restrictions. Does the package contain the report itself, a filing status, FIU feedback, law-enforcement intelligence, privileged advice or material whose disclosure could compromise an investigation? If yes, apply the specific rules for that data class. Redaction may be possible; sometimes the disclosure must be declined or escalated.

The sixth step covers cross-border and security conditions. Is the recipient in another jurisdiction? Where will the data be stored? Is the transfer mechanism approved? Is a vendor involved? Are onward transfers controlled? Are encryption, authentication, access logging and retention arrangements appropriate to the sensitivity?

Finally, record the outcome: share, share after redaction/minimisation, decline, or escalate. The system should retain the reason, authority, payload version and approver rather than only a status such as completed.

Decision flow for determining whether financial-crime information can be shared, minimised, declined or escalated

System and data architecture

In a mature bank, information sharing should not depend on copying screenshots into email. A controlled disclosure service can sit between authoritative source systems and external or cross-entity recipients. The source systems remain responsible for customer, transaction, case and screening data. A policy and entitlement layer determines who may request or approve which type of disclosure. The disclosure service selects the required data, applies masking or redaction, creates an immutable package version, sends it through an approved channel and records the event.

The system should maintain provenance. For every shared field that matters, the bank should know the source system and record key, when the value was effective, when it was retrieved, whether it was transformed, and which case or request caused it to be included. Provenance becomes crucial when information changes. A customer address viewed today may not be the address that existed when a disclosure was made six months ago.

It should also distinguish business effective time from retrieval time. A risk rating retrieved at 10:00 may have been calculated two weeks earlier. A sanctions-list result may depend on the list version used at the time. A payment-status field may change from pending to rejected after the disclosure. The evidence package should preserve the decision-time snapshot so later reviewers do not unknowingly assess the case using future information.

Entitlements need context. A simple role such as AML_ANALYST may be too broad. The correct decision may depend on legal entity, jurisdiction, case assignment, recipient type, information class and purpose. Sensitive disclosures may require maker-checker approval. Emergency routes can exist, but they should be logged and reviewed rather than bypassing the control silently.

The bank should also control exports. Downloading a spreadsheet can defeat carefully designed application permissions because the file then travels through email, local drives and collaboration tools. Export formats should apply the same field-level policies as the screen, include classification labels where useful, and use approved secure transfer methods. Data-loss-prevention monitoring can provide an additional layer but should not substitute for preventive workflow design.

Control architecture connecting authoritative sources, policy and entitlements, a disclosure service, secure channels and recipient controls

Information sharing in payments and investigations

Payments create time pressure that makes sharing design especially important. When a customer reports an authorised push-payment scam, the sending bank may need to contact the receiving institution quickly. The receiving institution may be able to hold funds, investigate the beneficiary, identify linked accounts or escalate to its own fraud and AML teams. The information required for urgent recovery is not necessarily the same information required for a later money-laundering investigation. A good process separates the immediate operational message from broader intelligence sharing and applies the correct gateway to each.

Correspondent banking creates another pattern. A correspondent may ask a respondent bank for information about an originator, beneficiary, transaction purpose or underlying customer. Such requests can support due diligence, sanctions compliance or investigation of unusual activity. The respondent should validate the request, retrieve authoritative information, apply local confidentiality restrictions, document the response and track non-response or repeated weak answers. A request for information is not itself proof that the customer is suspicious, but repeated RFIs can become relevant risk information.

Instant payments compress the time available for fraud prevention. Institutions increasingly use beneficiary intelligence, confirmation-of-payee style checks, mule-account indicators and consortium data to intervene before settlement. The faster the decision, the more important it is that shared risk data has clear provenance and defined semantics. A stale or ambiguous “high-risk payee” flag can block legitimate customers at machine speed. The control must therefore address freshness, confidence, challenge, correction and customer remediation as well as transmission.

Virtual assets introduce additional parties and data types: wallet addresses, blockchain transactions, VASP identifiers, Travel Rule data, device information and blockchain-analytics assessments. Some information is publicly observable on-chain; linking an address to an identified customer is not public merely because the ledger is. Banks and VASPs should distinguish open blockchain data from private identity mappings, vendor intelligence and protected investigation information.

Customer impact and fairness

Information sharing can improve customer protection by allowing institutions to recognise scams, mule networks and identity abuse sooner. It can also harm customers if weak data is propagated without context. A false match shared across several institutions can become self-reinforcing: one bank’s unverified suspicion becomes another bank’s risk factor, which is then interpreted by a third bank as independent corroboration.

For that reason, the shared object should identify whether information is a verified fact, customer-provided statement, system alert, analytical inference, unresolved allegation or formal legal status. Confidence should be explained where used. The source should be identifiable. Where law and operational constraints permit, correction mechanisms should exist for materially inaccurate information. A bank should not promise a customer access to information that law prohibits it from disclosing, but it should have an internal process for investigating data-quality complaints.

Financial inclusion matters as well. Over-broad risk sharing can drive de-risking of customers, sectors or geographies rather than targeted control. The objective is not to create a hidden blacklist assembled from weak signals. Strong sharing should help institutions distinguish the risky network from the wider population by bringing better evidence to the decision.

What good looks like

A strong information-sharing framework is surprisingly concrete. Staff know which sharing lanes exist. The legal and policy gateways are mapped by entity and jurisdiction. Data classes are defined. SAR/STR confidentiality is technically protected. Requests and disclosures use structured workflows. Data is minimised. Recipient identity and purpose are verified. Cross-border and security requirements are checked before transmission. The shared package preserves provenance and effective time. Exceptions are visible. Retention is controlled. Management can measure the process without encouraging excessive sharing.

Most importantly, the control is designed for judgement. Technology can enforce mandatory checks and prevent obvious prohibited exports, but it cannot resolve every conflict of law or ambiguous investigation. The workflow needs escalation routes to privacy, legal, the MLRO, FIU liaison, security or data governance without turning every normal disclosure into a legal project.

The aim is not maximum data movement. It is maximum useful financial-crime insight from the minimum justified disclosure. That is the point at which information sharing and data privacy stop looking like opposing objectives and become parts of the same control design.

Operational deep dive: making information sharing work in a bank

The difficult part of information sharing is rarely the abstract principle. The difficult part is turning a legal permission or obligation into an operating process that works when data is fragmented, cases are urgent, jurisdictions differ, investigators are under pressure and a later reviewer expects the bank to prove exactly what happened. This deep dive converts the principles in the base chapter into delivery, control and assurance practice.

Group-wide sharing without assuming the group is one legal person

A multinational bank often wants one view of financial-crime risk across its businesses. That is sensible. A customer may hold a retail account in one country, a corporate account in another, use cards issued by a third entity and make cross-border payments through a group payment company. A criminal network can exploit the organisational boundaries if each entity analyses only its own activity.

The technical temptation is to solve this with a single global data lake and broad group access. The legal and control question is more demanding. Which legal entity collected the data? For what purpose? Which group entities need it? Which data classes may cross borders? Is the recipient acting as another controller, a processor, part of a group-wide AML function or under another legal arrangement? Are there local secrecy, localisation, FIU or law-enforcement restrictions? Does the source jurisdiction limit onward disclosure of information received from public authorities?

A good group architecture starts with a jurisdiction-and-data matrix, not merely a network diagram. Rows can represent information classes such as customer identity, beneficial ownership, transaction facts, screening results, risk ratings, fraud intelligence, investigation notes, SAR/STR status and FIU intelligence. Columns can represent source and recipient entities or jurisdictions. Each intersection identifies the permitted purpose, legal gateway, restrictions, required approval, retention rule and whether redaction or aggregation is required.

This matrix should be maintained as controlled policy data rather than a static spreadsheet forgotten after implementation. Regulatory change can alter a route. A new group entity can create a new transfer. A cloud migration can change processing location. An acquisition can introduce customer data collected under a different legal framework. The bank needs an owner who can translate those changes into system rules and regression testing.

The group case platform should also support selective visibility. A group investigator may need to know that another entity has a relevant case without automatically seeing every document. A useful pattern is staged access: first expose a minimal index such as subject identifiers, case category, owning entity and contact point; then permit deeper access only when the purpose and gateway have been established. This reduces unnecessary replication while preserving the ability to connect risk.

Group-wide sharing should not destroy local accountability. The entity that owns the customer relationship still needs to understand the risk decision affecting that customer. A central investigation team can support analysis, but a local entity may retain legal responsibility for filing, customer restrictions, recordkeeping or regulatory engagement. Workflow should therefore capture both the analysis owner and the legal decision owner where they differ.

Public-private and interbank partnerships

Public-private partnerships can expose patterns that individual firms cannot see. A bank may identify a cluster of mule accounts; a payment firm may identify a device or beneficiary pattern; a public authority may provide typology information that changes how both interpret activity. FATF’s July 2026 report found a broad global landscape of these partnerships and emphasised the importance of legal foundations, governance and data-protection arrangements.

The most mature design does not begin by deciding what data everyone would like to have. It begins with a defined use case. Examples might include identifying a particular fraud typology, tracing a laundering network, improving detection of trafficking proceeds, or responding to a defined threat assessment. The partnership then defines who may participate, what information categories are in scope, what thresholds or triggers permit sharing, how requests are authenticated, what the recipient may do with the information, and how errors or misuse are handled.

Membership alone should not give unrestricted search access. If ten institutions participate in a partnership, that does not necessarily mean every analyst at every institution should be able to query every participant’s customer data. Controls can use purpose-bound queries, restricted investigator roles, case-level approvals, pseudonymised matching, secure clean-room approaches or other privacy-enhancing designs where appropriate. The technology should reflect the legal model rather than creating broader access simply because it is technically possible.

A partnership also needs a semantic model. One participant’s “fraud confirmed” status may mean a customer admitted fraud; another may use the same label when its internal investigation reached a balance-of-probabilities conclusion. A “mule” tag may refer to a suspected receiving account, a closed account, or a law-enforcement-confirmed subject. Without shared definitions, institutions exchange labels that appear comparable but are not. The data contract should preserve status, source, date, confidence and definition.

False positives require governance. If Bank A shares an erroneous link and Bank B acts on it, how is the correction propagated? If an identifier was mistyped, can downstream users discover the update? If the original source changes its conclusion, does the partnership support a correction event? Data-quality remediation is part of the sharing control, not an optional service feature.

In the European Union, Article 75 of Regulation (EU) 2024/1624 illustrates how law can formalise partnership controls. The provision limits sharing to what is strictly necessary for specified AML/CFT purposes, requires participant responsibility and supervisory verification, and refers to a data-protection impact assessment. It also defines permitted information categories and requires internal policies around sharing. These requirements belong to the EU framework and should be implemented according to its scope and application timetable; they are not a general global rule. For architects and BAs, however, the provision is a useful example of why partnership design needs both policy and system controls.

US Section 314(b): a specific safe harbour, not a universal template

Section 314(b) is frequently cited in global-bank discussions and equally frequently misunderstood. It is a United States statutory framework that provides a safe harbour for eligible participating financial institutions and associations that share information for the specified purpose of identifying and, where appropriate, reporting activity that may involve money laundering or terrorist activity. FinCEN’s current 314(b) page also explains that qualifying information may include fraud and other specified unlawful activity in the relevant context.

FinCEN issued an updated 314(b) fact sheet on 12 June 2026 and rescinded the older December 2020 fact sheet. The same date, FinCEN announced updated guidance clarifying information sharing about suspected fraud under the framework. A US bank using 314(b) should therefore rely on the current 2026 material rather than an old procedure copied from prior guidance.

For a global bank, the lesson is broader than the US rule itself: every sharing mechanism needs versioned legal provenance. The case workflow can record gateway = US_314B, the participant-registration status, the policy version and the date the gateway was evaluated. When guidance changes, the bank can identify affected procedures, controls and disclosures. A generic field such as information_sharing_allowed = yes loses that traceability.

The safe harbour also does not eliminate the need to protect information. Recipient verification, secure transmission, access control, purpose limitation and confidentiality remain operationally important. Nor should a bank assume 314(b) authorises disclosure of a SAR or its existence. SAR confidentiality remains a distinct boundary.

SAR/STR confidentiality: separate the underlying facts from the protected report

Financial-crime systems often create unnecessary risk by storing everything in one narrative. Consider an investigator note that says: “Customer received four credits from scam victims, transferred most funds to Exchange X, prior SAR filed last month, FIU requested continued monitoring.” That sentence mixes underlying transaction facts, investigator analysis, the existence of a SAR and FIU-derived information. If the bank later wants to share the scam-payment facts with an authorised peer, simple export of the note can disclose protected information accidentally.

A better data model separates those elements. Transactions are transaction objects. Case observations are case objects. Suspicion decisions are structured decisions. SAR/STR records are stored in a protected domain. FIU communications carry a source and dissemination restriction. The case renderer can show them together to an authorised investigator while the disclosure service selects only fields permitted for the specific sharing route.

This design also helps with tipping-off controls. Tipping-off restrictions are jurisdiction-specific, but the common operational concern is that a person should not be informed in a way that compromises a suspicious-activity report or investigation where the law prohibits that disclosure. Customer-service teams, relationship managers and operations staff therefore need guidance on what they can say when a transaction is delayed, additional information is requested or an account is reviewed. They do not necessarily need to know whether an STR/SAR has been filed.

The same principle applies to information shared within a group. A relationship manager may need to know that enhanced due diligence is required without seeing a protected SAR filing record. A central AML team may need the complete history. Entitlements should follow the decision right, not organisational seniority alone.

Cross-border information sharing and conflicts of law

Cross-border cases create the greatest temptation to use slogans. “GDPR allows AML sharing” is too broad. “Bank secrecy prevents any sharing” is also too broad. A real decision can involve the source country’s banking-secrecy law, data-protection rules, AML legislation, the recipient country’s legal powers, contractual obligations, localisation requirements and restrictions attached to information originally received from an authority.

A bank should therefore maintain an escalation route for true conflicts rather than expecting front-line operations to resolve them. The workflow can identify a cross-border destination and invoke the relevant rule set. If policy clearly permits the route, processing can continue. If the combination is unapproved or legally uncertain, the system routes the case to privacy/legal or the designated financial-crime policy owner.

Cross-border architecture also needs to consider where the data is processed, not only who sees it. A disclosure generated in Country A, sent through a group integration service in Country B, scanned by a security service in Country C and stored by a recipient in Country D creates a more complex data path than the business request suggests. Cloud-service regions, support access, backups and telemetry can all matter. Architects should document actual data flows and subprocessors rather than relying on the logical application diagram.

A controlled approach can use regional processing, field-level encryption, tokenisation, purpose-specific datasets, approved transfer mechanisms and restricted support access as appropriate. Those measures reduce risk but do not manufacture a legal gateway where none exists. Technology can support a lawful decision; it cannot substitute for one.

Disclosure evidence and the importance of time

A sharing decision is made at a point in time. Later, the customer profile, risk rating, case status and law may all change. Audit evidence should preserve what the bank knew and which rule applied when the disclosure occurred.

The evidence record should normally capture the request or trigger, purpose, recipient identity, source legal entity, destination, data classes, legal/policy gateway, policy version, approval, exact payload or an immutable reference to it, disclosure time, transfer channel and retention rule. If information was redacted, the reason should be reconstructable. If the request was declined, the outcome and reason should be logged as well.

A bank may not need to store a second full copy of every large dataset merely to prove disclosure; immutable hashes, package identifiers, versioned exports or other controlled references can support reconstruction depending on the system. The design choice should be made with legal, records and security teams so evidence is sufficient without multiplying sensitive data unnecessarily.

Evidence timeline showing the sharing need, authority check, minimised snapshot, disclosure, recipient use and lifecycle close

Time also matters for legal gateways. If a partnership agreement expires, a participant’s status changes, a regulator updates guidance or a statutory provision changes, the disclosure service should not rely on an undated configuration. Effective dating allows the system to answer: “Was this route approved on the date we used it?”

Governance and decision rights

Information sharing sits across several professional domains, so unclear ownership is a predictable failure mode. Financial-crime operations understand investigative purpose. Privacy and legal teams interpret lawful processing and transfer rules. Security and data teams control technical access and protection. The MLRO or equivalent function may own suspicious-activity reporting decisions and FIU engagement. Compliance oversight challenges control effectiveness. Internal audit provides independent assurance.

No one of those teams should quietly inherit all decisions. A useful RACI or decision-rights model distinguishes routine disclosures under an approved rule from exceptions that require specialist approval. For example, an authorised analyst might respond to a standard partnership query with transaction facts under a pre-approved gateway. A request containing SAR-status information would be blocked automatically and require MLRO/legal review. A new destination country would trigger privacy/legal assessment. An emergency law-enforcement request outside standard channels would route to the bank’s authority-response team.

Governance map showing financial-crime operations, privacy and legal, security and data, MLRO or FIU liaison, compliance oversight and independent assurance

Governance should monitor both under-sharing and over-sharing. If every request is rejected, the control may be legally cautious but financially ineffective. If nearly every request is approved with full data, the bank may be ignoring minimisation. Useful management information can include request volumes by route, approval and decline reasons, redaction rates, turnaround time, unresolved legal exceptions, access violations, corrections, incidents, stale partnership registrations and overdue retention actions. Metrics should support challenge, not create pressure to approve a target percentage of disclosures.

BA and architecture requirements

For a business analyst, “build an information-sharing solution” is not a sufficient requirement. The requirement set should define the actors, legal entities, jurisdictions, data classes, trigger, purpose, recipient types, gateways, approvals, security, evidence, exceptions and lifecycle.

A strong functional requirement might state: “When an authorised investigator requests disclosure to an external partnership member, the system must require a valid case identifier, purpose code, verified recipient organisation, approved legal-gateway code and requested data classes before payload generation.” That is testable. A companion rule might state that the system must prevent inclusion of fields classified as SAR/STR existence or FIU-restricted intelligence unless the selected gateway explicitly permits them and the required approval role has acted.

Data requirements should specify authoritative sources and semantics. If customer identity can come from both KYC and case management, which is authoritative? If an account-risk score is shared, does the value include the model version and effective date? If a transaction is reversed after sharing, is the recipient notified? If a customer belongs to multiple legal entities, how is the source owner identified?

Non-functional requirements matter. The system may need encryption in transit and at rest, strong authentication, field-level access control, tamper-evident logging, resilience, throughput for time-critical fraud cases, secure audit export and defined recovery objectives. Logging itself must be privacy-aware; a security log should not duplicate the entire disclosure payload unless genuinely necessary.

Architecture should avoid creating another uncontrolled intelligence silo. A central disclosure service can call source systems or receive purpose-built data products, but ownership of master data should stay clear. Interfaces should use stable identifiers and explicit schemas. Free-text email should be the exception, not the core integration pattern.

Testing the control

Testing should prove more than a happy-path file transfer. Positive tests confirm that an eligible request under a valid gateway produces the correct minimised package, routes to the verified recipient, records approval and preserves audit evidence. The test should compare source data with the output field by field.

Negative tests are just as important. Attempt to request information with no purpose, an expired partnership registration, an unauthorised recipient, a prohibited destination, a data class outside the gateway, or a user without the necessary entitlement. The system should fail safely and explain the reason without leaking sensitive information.

SAR/STR confidentiality tests should seed protected fields into the source case and verify they cannot appear in an ordinary external disclosure. Test both structured fields and free-text contamination. If users can paste SAR references into general notes, export controls need content inspection or, preferably, the process should redesign note capture to reduce the problem.

Minimisation tests should verify that selecting one defined purpose does not silently include unrelated customer fields. Regression testing is essential because schema changes can add new columns to an export. A new field from an upstream KYC system should not become shareable automatically merely because an integration uses SELECT * or serialises the whole customer object.

Cross-border tests should cover approved and prohibited routes, changes in destination, regional failover and vendor processing location. If a service fails over from an EU region to a non-approved region during disaster recovery, the bank needs to know whether that changes the data-protection posture.

Resilience tests should consider partial failure. What if the disclosure is delivered but the acknowledgement times out? A retry must not send multiple conflicting packages without tracking. What if the policy service is unavailable? The safe fallback may be to queue the request rather than default to allow. What if the recipient’s certificate expires? The exception should remain visible and owned.

Data-quality tests should use stale, conflicting and corrected information. If an investigator shares a customer’s old legal name, how is the discrepancy handled? If a source record is corrected after disclosure, does the system flag material corrections? If two customers share an identifier due to upstream error, can the control prevent cross-customer leakage?

Failure modes that look efficient until something goes wrong

One common failure is the email workaround. The official partnership portal is slow, so experienced analysts email spreadsheets directly to known contacts. The process feels practical until a contact changes jobs, a distribution list expands or sensitive columns are copied accidentally. If the approved channel is too slow for the business need, fix the channel rather than normalising bypass.

Another failure is global policy language with local implementation gaps. A policy may state that group entities “may share information for AML purposes” while local teams do not know which fields, purposes or approvals are actually permitted. The result is inconsistent behaviour: some teams refuse everything; others share everything. Translate policy into data- and route-specific rules.

A third failure is risk-label laundering. Institution A shares “high risk”; Institution B treats the label as verified criminal intelligence; Institution C later sees Bank B’s action and treats it as independent confirmation. The original weak signal becomes stronger each time it is copied. Preserve source, meaning and evidential status so downstream users do not mistake repetition for corroboration.

A fourth failure is uncontrolled onward sharing. The original recipient may have a valid reason to receive the information, but the bank does not specify whether the recipient can pass it to affiliates, vendors or other partnership members. The initial disclosure is then only the first step in a chain the source bank cannot explain. Agreements and technical controls should define onward use.

A fifth failure is permanent retention of intelligence because deletion feels risky. Keeping everything forever increases breach impact, complicates customer rights and allows old, low-quality signals to influence future decisions. Retention should reflect legal requirements, investigation needs and the purpose for which the information was shared.

Mini case study: a cross-bank mule network

Consider a composite scenario. Bank North receives reports from several retail customers who were deceived into making instant payments. The beneficiaries are accounts at Bank South. Bank North’s fraud team sees different victims paying three beneficiary accounts over two days. Each payment was individually authorised, so authentication alone does not prove the beneficiaries are legitimate.

Bank South sees a different picture. The three beneficiary accounts were opened recently, use different customer names, share device and address connections, receive funds from many unrelated senders and move most of the money onward within minutes. Some proceeds go to a crypto exchange; some go to a fourth account at another institution. Bank South’s monitoring has generated alerts, but none of the incoming payments alone exceeds a large-value threshold.

The two banks participate in a lawful information-sharing partnership in their jurisdiction. Bank North wants to ask whether the three beneficiary accounts are already linked to fraud concerns. Before sending the request, its workflow records the scam-investigation purpose, partnership gateway, recipient, victim-payment references and the minimum identifiers needed. It does not attach full victim KYC files. It also excludes any field indicating whether Bank North has filed a SAR/STR.

Bank South receives the structured request. Its disclosure service verifies membership and purpose, links the account identifiers to open investigations, and prepares an approved response containing relevant account identifiers, the fact that the accounts are under active financial-crime review, transaction references that overlap with the reported victims and a contact point for urgent recovery. Whether it may share more detailed suspicion information depends on the applicable partnership framework and local law. The response is not a declaration that the customers are criminals.

The combined intelligence changes both banks’ actions. Bank South can prioritise the linked accounts as a network rather than isolated alerts. Bank North improves beneficiary-risk controls and associates future victim reports with the same pattern. The partnership may escalate the network through its public-sector route where permitted. Each bank independently meets its own suspicious-activity reporting obligations; one bank does not disclose its SAR filing status to the other merely because they collaborate.

Now add a cross-border complication. The crypto exchange is in another jurisdiction and Bank South’s group crypto-risk team is located abroad. Before sharing identified customer data with that team or exchange, Bank South must use the relevant cross-border and legal framework, not assume the domestic partnership automatically extends to every recipient. If only wallet and transaction facts can be lawfully transmitted at that stage, the case can proceed with those facts while legal/privacy specialists assess whether identified customer data may follow.

This scenario shows why good information sharing is neither unrestricted openness nor defensive silence. Each participant contributes the information it can lawfully and usefully provide, the context remains attached, protected reporting information stays protected, and the combined picture is materially stronger than any institution’s fragment.

Practical close

A reviewer assessing an information-sharing control should be able to follow a straight line from purpose → gateway → data selection → confidentiality check → approval → secure disclosure → evidence → retention. If any step exists only in an analyst’s memory, the control is fragile.

The best design does not ask staff to become privacy lawyers. It converts approved legal interpretations into clear operational routes, keeps exceptions visible and ensures specialist teams decide the hard cases. It also does not turn privacy into a reason to tolerate preventable financial crime. Privacy-by-design can improve investigative precision by forcing teams to define purpose, evidence, accuracy and necessity.

For architects and developers, the test is whether the system prevents accidental over-sharing while enabling lawful, time-sensitive collaboration. For compliance and privacy teams, the test is whether policy can be translated into configuration, evidence and monitoring. For investigators and operations, the test is whether the process gives them enough information to act without forcing them to improvise legal decisions. For product owners and senior management, the test is whether the bank can demonstrate both effectiveness and respect for customer rights.

Advanced practice: acceptance criteria and assurance

A bank can make information-sharing policy operational by turning it into testable controls. The following acceptance criteria are deliberately technology-neutral so they can be implemented in a case platform, disclosure service, partnership portal or controlled API.

For every outbound disclosure, the system should require a financial-crime purpose, case or request identifier, source legal entity, verified recipient, destination jurisdiction where relevant, selected legal or policy gateway, requested data classes and the user or service identity initiating the action. A disclosure must not proceed when the selected gateway is expired, not approved for the source entity, incompatible with the recipient type or missing a required approval.

The payload generator should use an allow-list of fields for the chosen purpose rather than export the whole customer or case object and then attempt to remove sensitive fields. Data classified as SAR/STR existence, FIU-restricted intelligence, privileged legal advice or another protected category should be blocked by default and released only where the specific route explicitly permits it. Free-text fields require particular care because protected information can be pasted into otherwise ordinary notes.

The system should preserve an immutable evidence reference showing the exact payload version, source identifiers, effective dates, approval, disclosure time and transfer channel. A retry after network failure should be idempotent: the platform must determine whether the original package was delivered before creating a second disclosure. Corrections should create a traceable follow-up rather than silently overwrite the historical record.

Access testing should verify least privilege across entity, jurisdiction, role and case assignment. A user who can investigate a customer should not automatically be able to disclose that customer externally. A partnership administrator should not automatically be able to read case content. Support personnel should not gain broad production-data access merely because they maintain the platform.

Regression tests should run whenever a source schema, gateway rule, recipient list, partnership agreement, cloud region or data-classification policy changes. A new upstream field must not become externally shareable simply because an interface serialises it automatically. Failover should not send protected information through a region or vendor route that has not been approved.

Assurance should sample both approved and declined disclosures. Reviewers should ask whether the purpose was real, the gateway applied on that date, the payload was proportionate, confidentiality restrictions were handled correctly, the recipient was valid and the evidence trail is sufficient. They should also inspect cases that never reached disclosure, because excessive rejection can conceal an under-sharing problem just as excessive approval can conceal a privacy problem.

Privacy-enhancing techniques: useful tools, not legal shortcuts

Banks increasingly explore pseudonymisation, tokenised identifiers, secure matching, federated analysis and other privacy-enhancing techniques to reduce the amount of identifiable data exposed during collaborative analytics. These approaches can be valuable when two institutions need to discover whether they are observing the same subjects or transaction network before exchanging full identity data. For example, a controlled matching service can reveal that two participants hold records linked to the same identifier while limiting broad visibility of each participant's customer population.

The technique must still fit the legal and operational purpose. Pseudonymised data can remain personal data where re-identification is reasonably possible, and a cryptographic transformation does not automatically make a prohibited disclosure lawful. The bank still needs a permitted purpose, appropriate governance, security, retention and a defined process for moving from a privacy-preserving match to identified information where further investigation requires it.

Architecture teams should also examine leakage through metadata. A supposedly minimised dataset can still reveal sensitive information through timestamps, rare transaction patterns, small populations or repeated queries. Query controls, minimum cohort sizes where appropriate, rate limits, output review and monitoring for reconstruction attempts can therefore be as important as masking direct identifiers. The design depends on the use case; there is no universal privacy technology that removes the need for legal analysis.

Measuring whether the control actually works

Management information should test both financial-crime effectiveness and privacy discipline. Useful measures include disclosure volumes by gateway, ageing of pending requests, rejection and escalation reasons, proportion of packages requiring redaction, incidents of unauthorised access, recipient-validation failures, correction events, expired partnership credentials, retention exceptions and unresolved cross-border questions. For urgent fraud collaboration, elapsed time from validated request to usable response can also matter because funds may move beyond recovery quickly.

Metrics need interpretation. A falling disclosure volume may mean better minimisation, or it may mean investigators have stopped using an unusable process. A high approval rate may reflect a mature pre-screened workflow, or weak challenge. A high redaction rate may show healthy controls, or poor source-data segregation. Governance forums should therefore review examples and root causes rather than treating a dashboard threshold as proof of effectiveness.

The strongest control measures quality of justified sharing, not volume. The objective is neither to maximise nor minimise disclosures. It is to ensure that useful financial-crime information moves when it should, does not move when it should not, and remains explainable after the urgency of the original case has passed.

References and further reading