Conflicts of Interest and Internal Threats

A bank spends enormous effort deciding whether customers, counterparties and transactions can be trusted. It must apply the same discipline to the people who operate its controls. An employee can have legitimate access to customer information, payment systems, procurement workflows, sanctions alerts or credit decisions and still use that access for an undisclosed private interest. A manager can influence a decision without touching a system. A contractor can have privileged technical access without appearing in the employee population. A trusted insider can collude with an external customer, vendor or criminal group. These risks are difficult precisely because the person often begins with valid authority.

A conflict of interest is a condition in which a person's private, family, financial, professional or other secondary interest could improperly influence, or reasonably appear to influence, the performance of their duties. The existence of a conflict is not proof of corruption or misconduct. Many conflicts can be managed transparently through disclosure, recusal, independent review, reassignment or other safeguards. The danger begins when the conflict is hidden, poorly assessed, inadequately mitigated or combined with influence over a valuable decision.

An internal threat, or insider risk, is broader. It arises when a person with trusted access, knowledge or authority can harm the bank, its customers or the financial system from within. The behaviour may be deliberate, collusive, coerced or, in some security contexts, negligent. In a financial-crime course the most important cases are deliberate misuse of position, concealment of misconduct, facilitation of bribery or fraud, manipulation of financial-crime controls, unauthorised disclosure, and collusion with external actors. The concepts overlap but are not interchangeable: a conflicted employee may behave properly, while a malicious insider may have no conventional conflict of interest at all.

Why banks treat this as a control problem, not just an ethics problem

The consequences of an unmanaged conflict can travel through ordinary banking processes. A relationship manager may favour a company owned by a relative. A credit approver may support financing in which they have an undisclosed economic interest. A procurement manager may steer work to a connected supplier. A sanctions analyst may suppress a potential match because the customer is personally known to them. A payment operations employee may override a hold to assist an external conspirator. A privileged administrator may change access or logging so that another insider can alter KYC, beneficiary or case data without an obvious trace.

Those examples show why an employee-code declaration alone is not enough. Effective control links the human relationship to the business decision, the system entitlement, the approval path and the evidence trail. A declaration stating that an employee has an outside business interest is useful only if the bank can determine whether that interest intersects with customers, suppliers, investments, cases or decisions the employee can influence.

The Basel Committee's current corporate-governance guidance expects banks to identify and manage conflicts of interest and emphasises internal controls, segregation of duties and independent monitoring. Its compliance-function guidance also recognises that the compliance function itself can be compromised if conflicting responsibilities or insufficient independence weaken challenge. Those are governance principles for banks, not a global criminal-law definition of a conflict.

The European Banking Authority's internal-governance guidelines provide a more specific EU prudential example. They address conflicts affecting management bodies and staff and describe relevant interests and relationships that institutions should consider. Those expectations apply within their legal scope; a global bank should map them to the entities and jurisdictions to which they apply rather than treating one regional rulebook as universal law.

FATF approaches the issue from another direction. Recommendation 18 and its interpretive note require financial institutions, within the applicable AML/CFT framework, to maintain internal policies, controls and procedures, compliance arrangements, employee screening where appropriate, ongoing training and independent audit. FATF does not create a universal employee-conflicts regime. It does, however, reinforce why integrity, independence and effective internal control matter to AML/CFT effectiveness.

In the United States, the FFIEC BSA/AML Examination Manual similarly expects sound internal controls, including clear responsibilities and, where possible, dual controls and segregation of duties. That is U.S. BSA/AML examination guidance. The principle is useful globally, but the legal and supervisory status must remain correctly scoped.

A useful mental model: interest, influence, action and concealment

A practical way to analyse a conflict is to separate four questions.

What is the interest? It may be ownership in a company, a close family relationship, outside employment, a directorship, a financial investment, a political or charitable role, a personal relationship, a debt, a promised future job, or another benefit. Policies differ on which interests must be declared. The important design point is that the bank records enough structured information to understand the relationship without collecting excessive personal data merely because it might be useful someday.

What can the person influence? A conflict becomes operationally important when the individual can approve, recommend, select, investigate, suppress, change or access something connected to that interest. Influence can come from formal authority or informal seniority. A manager who does not press the final approval button may still shape a shortlist, steer a junior employee, define a technical requirement around one vendor, or control which information reaches a committee.

What action occurred? The bank should distinguish a declared potential conflict with no affected decision from behaviour that changes an outcome. Relevant actions can include an unusual approval, override, case closure, limit change, vendor-master amendment, exception, payment release, access grant, customer onboarding decision or information disclosure. A relationship alone is not evidence of wrongdoing, and an unusual action alone does not prove the reason behind it.

Was anything concealed or misrepresented? Concealment changes the risk picture. A stale declaration, false answer, use of a personal email, avoidance of maker-checker controls, repeated delegation to friendly approvers, manipulation of logs or pressure on another employee can indicate intent or awareness. Even here, investigators should establish facts rather than infer guilt from one anomaly.

This model helps prevent two opposite errors. The first is under-reaction: treating a declared relationship as an HR formality even when it intersects with a high-value business decision. The second is over-reaction: treating every shared surname, address or external role as misconduct. Mature controls ask whether the interest and influence actually intersect and what evidence exists about subsequent behaviour.

Where internal threats can appear in the banking lifecycle

At onboarding, an insider may help a connected customer bypass KYC evidence or risk classification. During customer maintenance, they may change addresses, beneficial-owner information, expected activity or risk attributes. During payment processing, they may release exceptions, change beneficiary data, repair messages selectively or reveal internal screening logic. In transaction monitoring, they may close alerts without adequate rationale or direct cases away from certain accounts. In sanctions operations, they may disclose that a payment is being held or manipulate a match decision. In lending, they may alter financial information or override policy. In procurement, they may shape tenders, supplier selection, purchase orders or bank-account changes. In technology, privileged users may manipulate entitlements, logs, configurations or data feeds that multiple controls depend on.

The threat can also be indirect. An employee may give a customer advance warning of a control change, share confidential information, leak investigation details, or tell an external party how to structure activity around a monitoring threshold. A staff member with no payment authority can still create significant risk if they have access to customer data or control logic.

This is why role design matters. The question is not simply whether an employee is trustworthy. Good control assumes that mistakes, pressure, compromised credentials, coercion and misconduct are possible and limits the amount of damage any one person can cause without independent visibility.

Declarations are a beginning, not the control outcome

A conflict-management process normally needs several triggers. New joiners may provide required declarations during onboarding. Employees can be asked to refresh information periodically. Event-driven declarations matter when someone changes role, joins a committee, receives a new outside appointment, develops a relevant financial interest, begins a close relationship or becomes involved in a decision touching an existing interest. The precise duty to disclose should follow applicable law and bank policy.

A useful declaration register stores the employee identifier, the type of interest, relevant connected party or organisation, effective dates, date declared, supporting evidence where appropriate, assessment, decision, mitigation, approver, review date and closure reason. Free text can explain nuance, but core data should not be trapped entirely in prose. Effective dates are especially important. An investigator looking at a decision from nine months ago needs to know what was declared and what role the employee held at that time, not merely today's state.

The outcome should also be specific. Conflict acknowledged is not a mitigation. A workable outcome might state that the employee must not participate in a named supplier selection, that approvals are rerouted to an independent manager, that system access is removed for the affected portfolio, that a second reviewer is mandatory, or that the relationship is monitored for a defined period. Where the conflict cannot be adequately managed, policy may require reassignment, cessation of the external interest or another decision. Employment and privacy law can constrain what measures are appropriate, so global procedures need local legal mapping.

Segregation of duties and privileged access

Segregation of duties converts the abstract idea of independence into system design. The same person should not be able to create and approve a sensitive vendor, initiate and release a high-risk payment, configure a screening rule and approve its own bypass, or change a privileged entitlement and erase evidence of the change. Banks implement this through maker-checker patterns, dual control, approval thresholds, role-based access, privileged-access management, independent reconciliation and immutable or strongly protected logs.

Segregation is not perfect merely because two user IDs appear in a workflow. Two colluding insiders can defeat nominal maker-checker control. A manager may share credentials. A service account may bypass the front-end approval. An administrator may have database-level access that the business workflow does not record. Testing therefore needs to examine actual technical privilege, not only documented business roles.

Joiner-mover-leaver controls are central. When an employee moves from operations to investigations, changes geography, takes parental leave, leaves the bank or joins a sensitive project, access should be re-evaluated. Dormant entitlements are useful to an attacker because they sit outside the employee's current job description and may attract less oversight. Break-glass access should be time-bound, justified, logged and retrospectively reviewed rather than becoming a permanent route around normal approval.

Data relationships that make the control real

Conflict and insider-risk investigations are fundamentally data-integration problems. Relevant sources can include the HR master, organisation hierarchy, declarations, outside interests, connected-person information permitted by policy, customer and KYC records, vendor master data, procurement events, expense and gifts registers, payment history, case-management decisions, IAM and privileged-access logs, device or security telemetry, whistleblowing cases and audit trails.

The bank does not need to copy all of that data into one enormous repository. It does need reliable identifiers, governed interfaces and a way to reconstruct relationships. An employee number should map consistently to user accounts. A vendor should have a stable internal identifier even if its trading name changes. A customer relationship should preserve beneficial-owner and controller history. Approval records should retain who actually decided, not only the team queue to which the task was assigned.

Entity resolution can surface useful connections such as a common address, telephone number, email domain, bank account, director or beneficial owner between an employee and a supplier or customer. Those signals require careful handling. Common surnames, apartment buildings, family-shared addresses or recycled phone numbers can create false associations. Sensitive personal data may require additional safeguards. A graph connection is a lead to examine, not a conclusion that misconduct occurred.

Detecting internal misuse without turning monitoring into suspicion by default

Monitoring works best when it focuses on control-relevant behaviour. Examples include repeated self-approved or closely connected transactions, high concentrations of overrides, unusual access outside role or working pattern, repeated closure of alerts involving the same customer network, access to accounts without a business reason, vendor-bank-account changes followed quickly by payments, repeated use of emergency privileges, attempts to disable logging, or unusual correlations between employee actions and customer activity.

The value comes from combinations. One override may be legitimate. One late-night login may reflect a production incident. One shared address may be innocent. An undeclared family link to a supplier, followed by steering of the tender, repeated bypass of procurement controls and a vendor-account change shortly before payment creates a much stronger evidence picture.

Detection design must also respect worker privacy, employment law, collective arrangements and local restrictions on employee monitoring. The bank should define legitimate purpose, approved data sources, access controls, retention, human review and escalation. Surveillance that is technically possible is not automatically lawful or proportionate.

Speak-up channels and the role of human intelligence

Many insider cases begin with a person noticing behaviour that systems cannot see: pressure to approve, instructions to avoid a control, unusual closeness to a vendor, retaliation after challenge, or deliberate exclusion of independent reviewers. A trusted speak-up or whistleblowing channel therefore complements analytics.

Wolfsberg's anti-bribery and corruption guidance supports confidential reporting arrangements, where legally permissible, protection against retaliation, timely investigation and remediation. Jurisdiction-specific whistleblower laws can add detailed requirements. The EU Whistleblower Directive, for example, creates a legal framework within the EU and has been transposed through national law; a global bank should follow the applicable national implementation rather than assume one operating rule worldwide.

The organisation also needs an alternative route when the normal manager is implicated. A system that automatically sends every employee concern to the employee's line manager can destroy confidentiality and create retaliation risk. Case routing should be able to bypass conflicted managers and direct sensitive cases to authorised HR, Compliance, Legal, Security or investigation teams.

From signal to investigation

A good triage process first asks whether immediate containment is required. If an insider can still release payments, alter evidence, access confidential investigations or change privileged settings, the bank may need to restrict access before the factual review is complete. Containment should be targeted and legally supported; it should not be confused with a final disciplinary conclusion.

Evidence preservation follows. Investigators may need approval history, access logs, email or collaboration records where lawfully obtainable, system-change records, declarations, vendor or customer ownership information, transaction data and relevant communications. Chain of custody and access restrictions matter because the subject may be a colleague with knowledge of internal systems. Investigation data should be separated from normal business access and limited to people with a legitimate need to know.

The investigation then tests competing explanations. Was an apparent conflict declared? Was the employee actually involved in the decision? Was there a valid delegation? Was the override within policy? Did the employee benefit? Did another person use their credentials? Did a system migration create the anomalous log? This discipline prevents a detection model from becoming the judge.

Outcomes may include no issue found, conflict recorded and mitigated, process remediation, access change, training, disciplinary action, recovery action, vendor or customer review, broader lookback, or referral to Legal, Security, Compliance, law enforcement or an FIU where applicable. Whether a suspicious-activity report, regulatory notification or other external filing is required depends on jurisdiction and facts. Confidentiality and tipping-off restrictions must be handled under applicable law.

Customer and market impact

Internal misconduct is often discussed as an employee issue, but customers can be directly harmed. An insider can cause unauthorised payments, unfair credit outcomes, inappropriate account restrictions, leakage of personal data or misuse of confidential commercial information. A poorly managed investigation can create a second harm if the bank freezes a legitimate customer's activity merely because an employee relationship is being examined.

Operations should therefore separate employee containment from customer disposition. Restricting an employee's entitlement does not automatically mean the connected customer is criminal. The customer may require enhanced review, transaction monitoring or temporary controls depending on evidence, but those actions need their own legal and risk basis.

Governance: no single team owns the whole risk

The first line owns day-to-day conflicts in its decisions and must apply recusal and escalation requirements. Compliance or an ABC function usually owns or challenges policy and higher-risk decisions. HR manages employment processes and sensitive employee data. Procurement and Finance own supplier controls. Information Security and IAM teams control technical access. Legal and specialist investigation teams advise on privilege, legal exposure and evidence. Internal Audit provides independent assurance. Senior management and the board or relevant committees receive material risk information and challenge whether the framework is effective.

That separation must remain practical. If Compliance is asked to approve every minor declaration, it becomes an operational bottleneck and may dilute its independent challenge role. If first-line managers can accept every conflict without second-line visibility, high-risk cases may disappear locally. Risk-based routing should distinguish routine, manageable declarations from significant conflicts involving senior staff, high-value decisions, control functions or suspected misconduct.

What good looks like

A strong bank can answer six questions quickly. What interest or insider-risk signal was identified? What business decision or system privilege could it affect? What facts support or weaken the concern? What containment or mitigation was applied? Who independently approved the decision? What evidence proves that the mitigation continued to operate?

That is a more useful standard than counting declarations. A large register can coexist with weak control if nobody checks whether the declared interests intersect with real decisions. Conversely, a smaller but well-governed process with event-driven updates, independent decisioning, access controls, reliable data links and defensible investigations can provide meaningful protection.

The central lesson is simple: a conflict is a condition to manage, not a verdict; an insider-risk signal is a reason to investigate, not proof; and trusted access should never mean unobservable access. The rest of this chapter develops the architecture, testing and investigation practices needed to make those principles work in a real bank.

Operational deep dive: how the control works across the bank

Conflicts and insider threats become difficult when they move between organisational boundaries. Human Resources knows who the employee is. Identity and Access Management knows what systems the employee can use. Procurement knows which vendors they influenced. KYC knows which customers and beneficial owners exist. Payment systems know which transactions were released. Compliance knows which declarations or alerts were reviewed. Investigations may need all of those facts at once. The operational challenge is therefore not simply to write a good policy; it is to make the relevant facts join reliably when a decision matters.

Building an end-to-end operating model

A practical operating model starts before a conflict appears. Recruitment and role assignment establish the employee identity, employment relationship and expected responsibilities. Depending on role, law and policy, the bank may conduct screening appropriate to the sensitivity of the position. Sensitive roles can include payment release, treasury dealing, procurement, financial-crime investigations, privileged technology administration and roles with access to confidential customer data. Screening is not a guarantee of future integrity. It establishes a baseline and confirms that the bank has applied the controls it considers appropriate for the role.

When the employee joins, the bank should make the duty to disclose understandable. Vague language such as “declare any conflict” produces inconsistent interpretation. Employees need practical examples: ownership or employment in an outside company, a close relative working for a supplier or customer, a board or charitable role that intersects with the bank, a material investment affected by a decision, a personal relationship with someone whose work they supervise, or a promised job with a counterparty they are negotiating with. The examples should not imply that every relationship is prohibited. They explain when independent assessment is required.

The register then needs workflow. A declaration can be submitted, awaiting information, under assessment, mitigation required, approved with conditions, closed, or another controlled state. The state should have a named owner and timestamp. An employee should be able to see what action they are expected to take. The assessor should see prior declarations, role and relevant policy. A manager should not approve a declaration in which the manager is themselves implicated.

Mitigation must flow into business systems where needed. If a procurement employee is recused from a tender, the sourcing platform should prevent or flag their participation. If a relationship manager is excluded from a connected customer's credit decision, workflow should route the case elsewhere. If an investigator is conflicted, case assignment should move without revealing unnecessary confidential information to the wider team. Merely placing a sentence in the declaration register while leaving all operational permissions unchanged creates a paper control.

Event-driven review

Periodic attestations are useful but insufficient. Conflicts change when roles and relationships change. Event-driven triggers can include promotion into an approval role, transfer to a sensitive function, assignment to a vendor-selection committee, appointment to an outside board, acquisition of a material interest, change in close relationship, new vendor onboarding, or discovery of a connection through another control.

A mature bank does not assume that every event can be automated. HR may know about a role change but not a private investment. Procurement may identify a shared address between an employee and vendor but not know whether the relationship is meaningful. Employees remain responsible for declarations required by policy, while analytics and business controls provide an additional layer rather than a substitute for personal accountability.

The difference between prevention, detection and investigation

These three layers are often mixed together.

Preventive controls reduce opportunity before anything happens. Examples include segregation of duties, recusal, role-based access, independent approval, vendor due diligence, restricted administration rights, mandatory leave in some sensitive functions, rotation, and controlled break-glass access.

Detective controls identify patterns after or as activity occurs. They include review of overrides, access anomalies, unusual approval concentrations, changes to vendor bank details, cases repeatedly closed by the same analyst, relationships between employees and counterparties, and exceptions from standard workflows.

Investigative controls determine what the signals mean. They gather evidence, test explanations, assess intent and benefit, establish scope, preserve confidentiality, decide remediation and evaluate external reporting obligations where relevant.

The layers should reinforce one another. A detector that repeatedly finds the same preventable issue should trigger control redesign. An investigation that discovers a previously unknown data relationship should inform monitoring. A preventive rule producing excessive operational work without reducing meaningful risk should be recalibrated.

Conflict taxonomy that supports decisions

Taxonomy matters because different conflicts require different responses. A bank may distinguish actual, potential and perceived or apparent conflicts. Exact terminology varies by policy and jurisdiction, but the operational distinction is useful.

An actual conflict exists when a current private interest intersects with a current duty or decision. For example, an employee is participating in the selection of a company they partly own.

A potential conflict could become actual if circumstances change. An employee may hold an outside directorship in a company that is not currently a bank supplier but is entering a tender.

A perceived or apparent conflict exists where an informed observer could reasonably question independence even if no improper influence occurred. Perception matters for trust and governance, but the bank should still assess facts rather than punish appearances mechanically.

Another dimension is the type of interest: financial, family, personal, external employment, directorship, political or public role, gifts and hospitality, future employment, debt or obligation, intellectual property, or other relationship. The register should be flexible enough to capture new forms without converting every nuance into an unmanageable code list.

Severity then depends on factors such as the value of the decision, influence held by the employee, sensitivity of the role, closeness of the connection, ability to conceal actions, prior conduct, customer or market impact and whether the conflict was declared promptly. Seniority can increase risk because informal influence may extend beyond formal entitlements.

Insider collusion: why two-person controls can still fail

Maker-checker design assumes independence between maker and checker. Collusion removes that assumption. Two employees can create and approve a fraudulent vendor, one can initiate a payment and another can release it, or an operator can work with an administrator to bypass workflow and logging. Therefore, a control environment needs detection beyond simple two-user evidence.

Useful measures include independent reconciliation, analytics across repeated pairs of approvers, review of unusual concentration in one vendor or customer, protected logs outside the control of the business process, privileged-session recording where appropriate, and periodic entitlement recertification. Teams should look for stable patterns: the same maker-checker pair repeatedly handling exceptions, the same senior person influencing nominally independent decisions, or the same administrator appearing shortly before sensitive data changes.

Collusion can also involve external actors. A customer may pay or pressure an employee to reveal internal thresholds. A supplier may offer a future job. A criminal group may recruit an operations employee to release payments or provide customer information. In such cases, customer financial-crime activity and employee misconduct are two sides of the same case. The bank needs a mechanism to link them without allowing one case team to expose restricted HR or whistleblowing information unnecessarily.

Privileged technology access as a financial-crime dependency

Financial-crime teams sometimes view privileged access as a cybersecurity issue owned elsewhere. That boundary is unsafe. Screening, transaction monitoring, KYC, case management and payment controls all depend on software, rules and data. An administrator who can modify a sanctions list, disable a scenario, change a customer risk score, alter an audit table or grant another user access can affect financial-crime outcomes even if they never review a customer themselves.

Architecture should identify high-impact privileges. Which users can change screening configuration? Who can alter transaction-monitoring thresholds? Who can edit reference data or customer risk attributes directly in a database? Who can deploy code to the payment hub? Can the same administrator change a control and the log proving the change? Is emergency access automatically revoked? Are service accounts tied to accountable owners?

A strong design separates administrative action from business decisioning and protects audit evidence. Technical administrators should not ordinarily be able to approve the financial-crime outcome generated by a change they made. Sensitive configuration should use controlled deployment, peer review, change tickets, versioning and rollback. Logs should be sent to a protected store that ordinary administrators cannot silently rewrite.

Investigating an employee linked to a customer or vendor

Consider an analyst who is discovered to share an address with the beneficial owner of a customer whose alerts the analyst repeatedly closed. The shared address is a signal, not proof. A defensible investigation would establish whether the address data is current, whether the people are connected, whether the analyst knew of the relationship, whether policy required declaration, whether the analyst actually made the closures, whether cases were substantively justified, whether other reviewers behaved similarly, and whether the customer activity itself is suspicious.

Immediate actions should be proportionate. If the analyst continues to have access to the customer and the risk of evidence alteration is material, the bank may reassign the cases and restrict relevant access while preserving the analyst's general employment rights and investigation confidentiality. If the data link proves to be a historic apartment building shared by unrelated people, the case may close quickly. The system should support both outcomes.

Investigators should avoid circular reasoning: “the employee is linked to the customer, therefore the closures are suspicious; the closures are suspicious, therefore the link must be improper.” Each proposition requires its own evidence.

Whistleblowing, retaliation and routing independence

Speak-up arrangements must be operationally separate from ordinary management channels when needed. A person reporting suspected misconduct by a manager should not be forced to send the concern through that manager. Cases involving senior leaders, HR staff, compliance staff or investigators may require specially restricted routing.

Wolfsberg's anti-bribery and corruption guidance supports confidential reporting, protection from retaliation where appropriate and timely investigation. The U.S. Department of Justice's Evaluation of Corporate Compliance Programs also asks how companies handle confidential reporting, protect against retaliation, investigate allegations and learn from findings. DOJ guidance describes how prosecutors evaluate programs; it does not itself create a global banking rule.

Case systems should record retaliation concerns as a distinct risk. Retaliation can include dismissal, demotion or overt pressure, but it can also be subtler: exclusion from work, negative treatment after a report, removal of responsibilities or threats to career progression. HR and Legal should determine the applicable employment-law response. The financial-crime team should understand that fear of retaliation can suppress reporting and distort control metrics.

Managing confidentiality when several functions are involved

Internal-threat cases create unusual information barriers. HR may hold sensitive employment information. Legal may assert privilege over advice. Security may possess technical logs. Financial-crime investigators may hold information subject to SAR confidentiality or local tipping-off rules. Whistleblowing identities may receive special protection. A single unrestricted case folder is therefore rarely appropriate.

The case model should separate common facts from restricted evidence. It can store references to protected evidence rather than copying everything. Access should follow role and need to know. Audit logs should show who viewed sensitive records. Exports should be controlled. If evidence must be disclosed to another function, the legal basis and purpose should be clear.

This design also protects the employee. Allegations can be damaging even when unsubstantiated. Investigation data should not become a permanent gossip repository accessible to managers who have no legitimate role.

Management information that measures effectiveness

Useful MI goes beyond the number of declarations or investigations. Management may need to know how many high-risk conflicts remain open beyond target review time, how often recusal controls fail, which functions generate repeated undeclared conflicts, whether joiner-mover-leaver events trigger timely entitlement changes, how many insider cases involve privileged access, whether investigations identify repeat root causes, and whether remediation closes on time.

Trend interpretation matters. A rise in reports may indicate worsening conduct, but it may also show increased confidence in speak-up channels. A fall in declarations may indicate fewer conflicts or weaker awareness. A very low substantiation rate may reflect noisy analytics, but a very high rate could indicate that employees report only when misconduct is already obvious. Metrics need narrative and independent challenge.

Common failure modes

One common failure is the annual-attestation illusion: the bank obtains a yearly declaration and assumes the risk is controlled until the next cycle. A conflict can arise the following day.

Another is register isolation: HR or Compliance records a conflict but no business workflow is changed. The employee remains able to participate in the affected decision.

A third is manager-only approval. Line managers understand the business but may themselves be conflicted, may value delivery over control, or may not recognise specialist financial-crime implications. Higher-risk categories need independent escalation.

A fourth is data overreach. In an attempt to detect every possible connection, the bank collects excessive employee and family information without clear purpose or protection. That creates privacy and trust risk. Detection should be designed with Legal, Privacy, HR and employee-relations expertise.

A fifth is technology blind spots. Business role matrices may be clean while database, service-account or emergency privileges defeat them. Technical entitlement testing must be part of the assurance model.

A sixth is case closure without remediation. An individual may be disciplined while the same control gap remains available to others. Every material case should ask what process, data, access or governance weakness allowed the event and whether a broader lookback is needed.

Operational standard

A defensible operating model can show the journey from employment and declaration through business decision, access, detection, investigation and remediation. It preserves historical facts, routes cases independently, constrains privileged power, tests collusion rather than relying on nominal maker-checker evidence, protects sensitive information and learns from confirmed cases. That is what turns a conduct policy into an effective financial-crime control.

Advanced practice: architecture, analytics and assurance

The hardest internal-threat controls sit where human behaviour meets technical privilege. A policy may say that conflicted employees must recuse themselves, but the product backlog must translate that sentence into identities, events, rules, workflow states, entitlements, evidence and exception handling. This section focuses on those delivery details.

Design the data model around relationships and time

A conflict is rarely a property of one person in isolation. It is a relationship between a person and another person, organisation, asset or role, combined with the duties the employee performs. The data model should therefore support relationships explicitly.

A practical model can contain an employee entity with stable employee ID, legal entity, organisational unit, role, manager, location and effective dates. A declared_interest can reference the employee, interest type, connected party, description, start and end dates, declaration date, evidence and assessment status. A mitigation can record the action, affected business scope, approver, start date, review date and expiry. Separate customer, vendor, case, account, payment, system_role and approval entities can then be linked when the use case requires it.

Temporal history is not optional. Suppose an employee became a vendor-selection committee member in March, declared a family relationship in June and was removed from the committee in July. A snapshot taken in September hides the period during which the conflict mattered. Effective-dated role history and declaration history allow investigators to reconstruct the state at the decision date.

The same applies to customer ownership, vendor bank details and system permissions. If an employee's relative sold a supplier before the tender, the current ownership graph may wrongly imply a conflict unless historical ownership is available. If the relative bought the supplier afterward, a current graph may create suspicion that did not exist at the time. The system needs “what did we know then?” as well as “what do we know now?”

Identity resolution without accidental accusation

Cross-domain matching is powerful and dangerous. Exact employee ID is reliable inside HR, but external connections are inferred from names, addresses, phone numbers, emails, directors, bank accounts or beneficial ownership. Those attributes vary in quality and sensitivity.

A safe entity-resolution service should preserve the evidence behind each proposed link. It should distinguish exact, normalised and fuzzy matches; record data source and effective date; and allow a human to reject a false link. A common surname must not be treated like a shared verified bank account. An apartment address containing hundreds of residents should not receive the same weight as a unique residential address. A corporate email domain may show only that two people work for the same large company.

The investigation interface should explain the linkage rather than display a mysterious “insider score”. Explainability is especially important when the subject is an employee because poor matches can affect employment and reputation.

Detecting abuse across business processes

Monitoring should be anchored in abuse opportunities.

In procurement, useful patterns include an employee repeatedly influencing awards to one supplier, short tender windows, repeated single-source exceptions, purchase-order splitting, rapid vendor-bank-account changes, unusual use of emergency procurement, or a connected employee participating after a recorded recusal. Each has legitimate explanations; combinations matter more than isolated events.

In payments operations, monitoring can look for unusually high override rates, repeated release of held payments for one customer network, approvals outside assigned portfolios, activity from emergency entitlements, changes immediately before release, or unusual maker-checker pairings.

In KYC and customer risk, a concern may arise when one employee repeatedly downgrades risk, waives evidence, approves exceptions or changes beneficial-owner data for connected customers. Peer comparison can help, but it must account for role and portfolio. A specialist handling complex cases naturally produces more exceptions than a junior reviewer handling simple retail customers.

In sanctions and AML operations, insider risk includes inappropriate alert suppression, leakage of match logic, deliberate manipulation of names or identifiers, misuse of investigation data, and unauthorised access to sensitive cases. Quality-assurance outcomes can be combined with access and relationship information to identify patterns requiring review.

In technology, relevant events include direct database changes, disabling of logging, unauthorised configuration deployment, creation of persistent privileged accounts, use of dormant service credentials, or changes to access-control policies. Security tooling may detect the technical event, while financial-crime context explains why it matters.

Analytics should generate hypotheses, not verdicts

Graph analytics can reveal that an employee is linked to a supplier through ownership or address data. Behavioural analytics can show that the employee approves that supplier at an unusual rate. Access analytics can show that a privileged administrator viewed or changed records outside their normal scope. None of those signals proves intent.

The analytics layer should therefore produce an investigable hypothesis with evidence references. For example: “Employee E134 has a verified family relationship declared with director D91. Vendor V220 is controlled by D91. E134 participated in two V220 sourcing events after the declared recusal date.” That is far more useful than “insider risk score 92”.

Models should be validated for data completeness, explainability and false-positive behaviour. A graph can miss a relationship because ownership information is stale. It can also overstate a relationship because entity resolution joined two different people. Detection quality should be measured against confirmed cases and sampled legitimate activity, with attention to disparate impact and privacy constraints.

Requirements that business analysts should make explicit

A requirement such as “the system shall detect employee conflicts” is not implementable. Delivery teams need to know:

• which employees and contractors are in scope;
• which declaration types and connected parties are captured;
• which business decisions or system roles are considered sensitive;
• which events trigger reassessment;
• what relationship evidence is authoritative enough to create a case;
• which users can view sensitive HR or whistleblowing data;
• when a conflicted manager must be bypassed;
• what recusal means in each connected application;
• whether the system blocks, warns, reroutes or merely records;
• what overrides are permitted, by whom and with what evidence;
• how long mitigations remain effective and how expiry is handled;
• how historical state is reconstructed;
• what audit evidence must be immutable or independently protected;
• and which local legal restrictions affect employee monitoring or data use.

A good user story is concrete. “When an employee with an active recusal from vendor V attempts to enter the vendor's tender workspace, the sourcing platform must deny participation and record the attempt, while an authorised procurement controller can view the reason code without seeing unnecessary personal details.” The acceptance criteria then test identity matching, effective dates, role changes, access denial, logging and authorised visibility.

Testing the control as an adversary would

Positive-path testing is not enough. If a declaration is correctly entered and a normal workflow reroutes approval, the easiest case works. Insider-threat testing needs to explore how controls are bypassed.

Test a role change where old access persists. Test a user who holds both business and technical roles. Test delegation to another user who is also connected to the vendor. Test a case in which the line manager is the subject of the allegation. Test a supplier name change that preserves the underlying entity. Test a connected party with different transliteration. Test an emergency entitlement granted during an outage and not revoked afterward. Test a direct database update that bypasses the front end. Test a log collector outage. Test a leaver account that remains active through a service credential.

Negative testing is equally important. A false entity match must be dismissible with evidence. Two unrelated employees with a common surname should not trigger permanent restrictions. A legitimate production-support engineer working late during an incident should not be labelled malicious simply because the access time is unusual. A declared family relationship should not be treated as misconduct when the employee was successfully recused.

Boundary testing should focus on effective dates and thresholds. What happens if a declaration becomes effective on the same day as a decision? If a role ends at midnight in one system and remains active until a nightly batch in another, which state governs? If a vendor bank-account change and payment occur within minutes, can monitoring correlate them before release or only afterward?

Segregation-of-duties testing beyond the user interface

A strong SoD test inventories all ways a sensitive action can be performed: user interface, API, batch, database, privileged console, service account and emergency access. The bank should confirm that a prohibited combination cannot be reconstructed through alternate channels.

Consider vendor payment. A user may be blocked from both changing vendor bank details and releasing a payment in the procurement application. But if the same user has database permission to change the bank account directly, the business control is ineffective. Similarly, an IAM administrator may be able to grant themselves a payment role temporarily unless privilege elevation requires independent approval and protected logging.

Testers should compare policy roles to effective technical rights. Role mining can identify combinations that no longer match job responsibilities. Entitlement recertification should use meaningful business descriptions rather than opaque technical group names that managers cannot evaluate.

Controls during outages and emergency access

Operational resilience can create insider-risk gaps. During a payment incident, teams may activate break-glass accounts, bypass normal queues or use manual procedures. Those arrangements can be necessary, but they should not erase accountability.

Emergency access should identify the individual user, reason, approved duration and scope. Shared emergency passwords weaken attribution. Actions should be logged to an independent store. After the incident, emergency rights should expire automatically where possible and receive retrospective review. If a control service such as conflict screening or relationship matching is unavailable, the business should have predefined degraded-mode handling for high-risk decisions rather than improvising under pressure.

Change management and regression risk

Internal-threat controls are affected by changes that may not be labelled as financial crime. An HR platform migration can change employee identifiers. A procurement system upgrade can remove a recusal field. A new identity provider can alter privileged-access logs. A merger can create duplicate employees or vendors. A cloud migration can introduce new service accounts. A case-management redesign can broaden permissions unintentionally.

Change impact assessment should ask whether identifiers, relationships, entitlements, logs, effective dates, retention or routing rules change. Regression tests should verify known high-risk journeys after each material change. Data reconciliation should prove that declarations and mitigation states survived migration accurately.

Assurance and quality review

Quality assurance should sample both high-risk and ordinary decisions. If QA looks only at confirmed misconduct, it cannot assess false positives or whether legitimate conflicts are being managed proportionately. Samples can include closed declarations, accepted mitigations, recusals, overridden restrictions, insider alerts, investigations and no-issue closures.

Reviewers should be able to answer whether the conflict was correctly classified, the relevant business influence identified, mitigation operationalised, independent approval obtained, customer impact considered, evidence preserved and follow-up completed. They should also check whether the case discovered a wider process weakness.

Internal Audit can then test the framework independently: governance, policy design, data lineage, access control, declaration completeness, monitoring, investigation quality, issue remediation and board reporting. Audit should not simply reperform case decisions; it should assess whether the system of control is reliable.

Root-cause analysis after a confirmed case

A confirmed insider event should never close with “employee dismissed” as the only remediation. The bank should ask how the action was possible. Was the conflict undeclared because training was unclear? Did a manager ignore it? Did a recusal exist only on paper? Did excessive privilege permit the action? Did logs fail? Did monitoring detect the event too late? Did colleagues hesitate to report concerns? Was a vendor or customer also involved?

Root causes should map to control owners and deadlines. If an employee suppressed AML alerts because one analyst could close high-risk cases without secondary review, the remediation is not only disciplinary. The bank may need workflow changes, retrospective case review, entitlement redesign, QA enhancement and examination of affected customers.

The same logic applies to procurement collusion, unauthorised payment releases and privileged technical manipulation. A mature programme learns from the mechanism, not just the person.

What to show a senior committee

Senior management needs enough information to challenge effectiveness without receiving unnecessary personal detail. Useful reporting can cover material cases, high-risk open conflicts, overdue mitigations, control breaches, privileged-access themes, whistleblowing trends, repeat root causes, investigation ageing, customer impact and remediation status.

The narrative matters. A rise in insider alerts caused by a new analytics model should not be presented as a sudden rise in employee misconduct. A reduction in declarations following a system migration may indicate a data problem rather than improvement. Material cases should explain control lessons and risk exposure, not sensationalise individuals.

The programme is effective when policy, identity, business workflow, access, analytics, investigation and governance agree on the same facts. If those layers contradict one another, the bank has a control gap even when each team can show its own green dashboard.

Practice close: applying the control in delivery and review

The most useful way to close this topic is to convert it into decisions a bank actually has to make. A good conflicts-and-insider-risk framework is visible in procedures, access rules, workflow, investigation evidence and testing. It is not proven by the existence of an employee handbook alone.

Worked scenario 1: the relationship manager and the connected borrower

A corporate relationship manager recommends an urgent credit-line increase for a long-standing customer. The customer is performing well and the request is commercially reasonable. During routine portfolio review, another employee notices that a newly appointed director of the borrower has the same surname as the relationship manager.

The correct response is not to reject the credit request or accuse the relationship manager. The surname is weak evidence. The reviewer should establish whether a relationship actually exists and whether bank policy requires it to be declared. If the director is a close relative and the employee can influence the credit decision, the bank has a relevant conflict even if the loan itself is good quality.

A proportionate mitigation may be to remove the relationship manager from the approval process, have an independent banker validate the business case and confirm that pricing and covenants are consistent with comparable customers. If the relationship was already declared and the employee had no approval authority, the existing mitigation may be adequate. If the employee concealed the relationship and pressured approvers, the matter becomes a conduct and possible investigation issue.

The learning point is that credit quality and conflict management are separate questions. A good borrower does not eliminate an employee conflict, and an employee conflict does not prove the borrower is fraudulent.

Worked scenario 2: the AML analyst who closes one network's alerts

An AML quality-review team identifies that one analyst closes a higher proportion of alerts for a cluster of related customers than peers do. The analyst's written rationales look plausible. A detection model flags that the analyst previously worked for one of the customers several years ago.

The prior employment is relevant context but not proof of misconduct. The investigation should check whether the relationship was declared, whether the analyst knew current staff or beneficial owners, whether case allocation was random, whether the closures met policy, whether comparable analysts reached similar conclusions and whether the analyst accessed the customers outside assigned cases.

If closure quality is sound and the historical connection is remote, the case may close with no issue. If the analyst repeatedly received the cases through manual reassignment, accessed them before assignment and omitted material red flags, the evidence becomes stronger. If a suspicious-activity report or related investigation is involved, applicable confidentiality rules become especially important.

The learning point is that monitoring must distinguish performance variation from intentional facilitation. Peer statistics create a question; case evidence answers it.

Worked scenario 3: emergency access during a payment outage

An instant-payment service suffers an operational incident. To restore service, an engineer receives emergency privileged access to a payment-routing component. The access is approved for four hours. The next morning the engineer still has the role because the automatic expiry failed.

Nothing improper may have happened, but the control has failed. The bank should remove the access, verify the actions performed, assess why expiry failed and test whether similar emergency roles remain active. If the engineer used the role to alter beneficiary or screening behaviour outside the incident scope, the matter escalates.

The learning point is that insider-risk control includes opportunity management. The bank does not wait for evidence of abuse before fixing unnecessary privilege.

Reviewer checklist for a conflict case

A reviewer should be able to reconstruct the following without guessing:

• the employee or contractor and their role at the relevant time;
• the private or secondary interest that created the possible conflict;
• the connected customer, vendor, person, asset or decision;
• how the relationship was identified and how reliable the evidence is;
• whether and when the interest was declared;
• which policy or local rule applied;
• what influence the person actually held;
• whether any business action occurred while the conflict existed;
• what mitigation or containment was applied;
• who made the independent decision;
• whether technical entitlements were changed where needed;
• whether customer or third-party impact required separate treatment;
• whether investigation, disciplinary or external-reporting analysis was needed;
• and whether remediation was completed and tested.

A file does not need pages of copied policy if those facts are clear. It does need enough evidence to explain why the final decision was reasonable.

Acceptance criteria for a declaration and recusal workflow

A product owner implementing a conflict-management workflow can use the following acceptance criteria as a starting point.

Identity and history. Every declaration must be linked to a stable employee or contractor identifier. Role, manager and legal-entity history must be effective-dated so historical decisions can be reconstructed.

Interest capture. The workflow must record interest type, connected party, relevant dates, description and any required supporting evidence. Mandatory data should be proportionate and privacy-approved.

Assessment. An authorised reviewer must be able to classify the case, request information, record rationale and apply a mitigation. The subject of the conflict must not approve their own mitigation.

Independent routing. Where the line manager is connected to the conflict or named in an allegation, routing must bypass that manager to an authorised alternative.

Recusal. A mitigation requiring recusal must identify the affected decision or business scope, effective date, owner and review or expiry date. Where technically feasible and proportionate, connected applications should enforce or warn on the restriction rather than relying on memory.

Audit trail. Changes to declarations, assessments and mitigations must retain user, time and prior value. Deletion should not destroy historical evidence needed for lawful retention and investigation.

Privacy. Users should see only information necessary for their role. A procurement controller may need to know that an employee cannot participate in a tender without seeing confidential family or personal information irrelevant to the decision.

Review. Event-driven reassessment should be possible when role, connected party, vendor/customer relationship or other relevant facts change.

Test pack: positive cases

Test A — declared supplier relationship. Employee declares that a sibling owns Supplier X. The employee later joins a sourcing committee where X is shortlisted. Expected result: the active mitigation is detected; participation is rerouted or blocked according to policy; the employee cannot approve the exception; audit evidence records the decision.

Test B — post-decision declaration. Employee declares an interest after having participated in a relevant decision. Expected result: the workflow does not treat the declaration merely as future-facing; it creates a review of prior affected activity according to risk and policy.

Test C — role change. An employee with no purchasing authority moves into procurement. Expected result: role-change event triggers review of relevant declarations and access; prior unrelated interests are reassessed for the new role.

Test D — privileged support. Administrator receives emergency access for an incident. Expected result: approval, scope and expiry are recorded; actions are independently logged; access expires automatically or is promptly revoked; retrospective review is generated.

Test E — insider alert. Monitoring identifies repeated payment overrides for a connected customer. Expected result: evidence links are available to authorised investigators; immediate access containment can be initiated without automatically deciding employee guilt.

Test pack: negative and boundary cases

False surname match. Two unrelated people have the same surname. Expected result: the relationship can be rejected with evidence and does not create permanent adverse status.

Historic relationship. Employee previously worked for a company that became a bank vendor years later. Expected result: policy and facts determine relevance; the system does not automatically classify all past employment as an active conflict.

Expired recusal. A conflict mitigation ended after the connected interest was disposed of and independently verified. Expected result: the employee is not blocked indefinitely; history remains visible to authorised reviewers.

Manager implicated. An employee reports suspected misconduct by the line manager. Expected result: the line manager receives no automatic notification or approval task.

Migration boundary. A declaration is migrated from a legacy system with a missing effective date. Expected result: it is identified as incomplete data and routed for controlled remediation rather than silently assigned today's date.

Shared vendor bank account. Analytics find the same bank account on two vendor records. Expected result: the signal is investigated; no employee is accused unless an employee connection or conduct evidence is established.

Time-zone boundary. A recusal becomes effective at a specified local time while a global platform stores UTC. Expected result: the business rule handles conversion consistently and testing proves that the employee cannot participate during the prohibited interval.

Test pack: adversarial cases

Colluding approvers. Maker and checker are separate user IDs but repeatedly work as a pair and both are connected to the same external party. Expected result: independent analytics and reconciliation can identify the pattern; nominal two-person control is not treated as conclusive assurance.

Direct database change. A privileged administrator changes vendor or customer data outside the user interface. Expected result: the change is logged independently, subject to change-control or privileged monitoring, and attributable to an individual identity.

Log tampering attempt. Administrator tries to delete or alter application audit data. Expected result: protected central logging preserves the event and generates an alert or investigation path.

Delegation bypass. A recused approver delegates work to a close colleague who follows informal instructions. Expected result: workflow captures the delegate decision and the case can be reviewed for actual independence; control design does not assume delegation automatically cures influence.

Service account misuse. A former employee's personal access is removed, but credentials to a service account they knew remain unchanged. Expected result: service accounts have accountable owners, rotation and privileged-use monitoring sufficient to identify the weakness.

What not to conclude too quickly

Several misconceptions repeatedly damage investigations.

“A conflict means corruption.” No. A conflict is a risk condition. The employee may disclose it promptly and comply fully with recusal.

“No declaration means no conflict.” No. The point of detection and investigation is partly to identify undeclared or newly arisen relationships.

“Two approvals mean the transaction is safe.” Not necessarily. Collusion, shared credentials or technical bypass can defeat formal segregation.

“An anomaly means malicious intent.” No. Operational incidents, role changes, poor data and legitimate exceptions create unusual patterns. Human investigation must test alternatives.

“Employee monitoring can use any data available to the bank.” No. Privacy, employment, secrecy and other legal requirements constrain collection and use. Monitoring requires legitimate, proportionate and governed design.

“The customer must be bad if an employee is conflicted.” No. Customer risk and employee conduct need separate evidence and decisioning.

“Dismissing the employee fixes the control.” No. The bank must remediate the mechanism that allowed the event and consider lookback across similar activity.

Questions for a BA or architect before signing off a design

Can the solution reconstruct employee role, declaration, entitlement and business decision as of a historical date? Can it route around a conflicted manager? Does recusal affect the systems where influence occurs? Can entity resolution explain why it believes two parties are connected? Are service accounts and administrator access in scope? Are logs protected from the users they monitor? Can a false relationship match be corrected? Are privacy and employment-law constraints documented by jurisdiction? Does the case model separate allegations from substantiated findings? Can remediation be tracked to completion? Does the workflow distinguish employee containment from customer disposition?

If the answer to several of those questions is “the procedure tells people what to do,” the technology design is probably incomplete.

Questions for an operations or compliance reviewer

What specific interest or insider-risk signal exists? What decision or privilege can it affect? What is the evidence quality? Has the person declared it? What happened during the period of overlap? Is immediate containment necessary? Who can investigate independently? What information is restricted? Does the customer, vendor or transaction require separate review? Is there an applicable local reporting requirement? What root cause must be fixed if the case is substantiated?

These questions keep the review fact-based and prevent a dramatic allegation from outrunning the evidence.

Chapter takeaways

Conflicts of interest are common in complex organisations and are not inherently misconduct. The bank's task is to identify relevant interests, understand the person's influence and manage the overlap transparently. Internal threats are broader because trusted access itself can be misused, with or without a traditional conflict.

Effective control combines declarations, event-driven review, segregation of duties, independent approval, least privilege, protected logging, speak-up arrangements, relationship analytics, disciplined investigation and root-cause remediation. None works well in isolation.

Data integration must be precise and proportionate. Employee, vendor, customer, payment, case and access records can reveal important relationships, but bad entity resolution can create false suspicion. Historical effective dates are essential.

Investigations should preserve evidence, test alternative explanations and separate signal from conclusion. Employee, customer and third-party outcomes need independent legal and risk bases.

The strongest design principle is also the simplest: make influence visible, make sensitive actions attributable, and make independent challenge possible before one person's private interest can become the bank's loss.

Masterclass: the connected vendor and the hidden control path

This case is fictional but deliberately realistic. It shows why a conflict register, procurement controls, payment controls and privileged-access controls must be analysed together. No single fact proves wrongdoing. The case becomes meaningful only when the evidence is joined in time.

The setting

Northstar Bank is replacing part of its customer-screening platform. The procurement is worth enough to require a competitive tender, technical scoring, procurement review and independent approval. A senior procurement manager, Elena, coordinates the commercial process. Six months earlier she completed an annual conflicts attestation and reported no relevant outside interests.

One bidder, Meridian Systems, is a relatively small reseller proposing software and implementation services from several technology vendors. Meridian passes ordinary supplier onboarding. Its corporate registry information identifies a director named Daniel, but the vendor file does not contain any link to bank employees. The bank's procurement application and employee conflict register are separate systems.

During the tender Elena recommends narrowing the shortlist from four vendors to two. Her rationale is plausible: one bidder lacks implementation capacity and another fails a mandatory security requirement. Meridian remains. Several colleagues notice that Elena is unusually involved in technical discussions despite her commercial role, but no one considers the behaviour serious enough to report.

Meridian wins. Two months later, the vendor asks to change its settlement bank account. The request arrives from a valid corporate email address and includes a bank letter. A finance analyst enters the new account. The maker-checker approval is performed by another finance employee. Payment proceeds normally.

The first signal

The case begins not with procurement but with an HR event. Elena updates an emergency-contact record after a family relocation. A data-quality control notices that the address matches a residential address associated with Daniel, Meridian's director, in a separate employee-vendor relationship analytics pilot. The connection is not automatically treated as misconduct. The tool creates a restricted review because address matching can be noisy.

An authorised reviewer verifies that Daniel is Elena's brother. The relationship was not declared. The reviewer then checks the conflict policy and confirms that close-family ownership or control of a supplier participating in an employee-influenced procurement is a relationship that should have been disclosed under the bank's policy.

At this point the bank knows three things: there is a family relationship, the supplier won a tender, and the employee participated in the tender. It still does not know whether the procurement decision was improper or whether Elena benefited.

Containment without deciding guilt

The investigation team and HR agree on limited interim measures. Elena is removed from further Meridian procurement decisions. Access to the relevant sourcing workspace is suspended. The bank does not immediately terminate her employment or block Meridian payments. Those would be conclusions ahead of evidence.

The investigation system places a preservation request over relevant tender records and approved communications under the bank's legal process. Procurement exports the scoring history. IAM preserves access and role history. Finance preserves vendor-master changes and payment approvals. Compliance checks the prior declaration record and its effective date. The case manager restricts access because the allegation concerns an employee and may include legally sensitive employment information.

The team also assesses customer and operational impact. Meridian supports a live screening-system implementation. Abruptly cutting the supplier off could harm an unrelated control programme. Business continuity therefore becomes part of the containment decision.

The evidence changes the picture

Tender history shows that Meridian did not have the highest original technical score. A scoring criterion was changed during clarification, after which Meridian's score improved. The change was documented, but Elena had requested it. That fact is concerning but not decisive because procurement managers commonly coordinate clarification.

Email and meeting records, collected under the bank's approved legal process, show that Elena repeatedly encouraged technical staff to interpret requirements in a way favourable to Meridian. More importantly, one analyst recorded an objection that the revised scoring method reduced differentiation between experienced integrators and resellers. Elena responded that the committee needed to “keep commercial flexibility.” Again, the phrase alone proves little.

The investigation then finds that purchase orders were divided into several smaller statements of work after award. The total remained within the approved programme budget, but the split reduced the number of individual invoices requiring enhanced approval. The procurement policy permits phased statements of work, so this is not automatically a breach. However, it increases the need to understand who authorised the structure and why.

Vendor-master logs introduce another issue. The finance analyst who changed Meridian's bank account had received an urgent chat message from Elena asking them to prioritise the request because the supplier was threatening to delay delivery. Elena did not perform the change or approve it. The request therefore falls outside a simple segregation-of-duties violation, but it demonstrates continuing influence over the supplier relationship.

The internal-threat dimension

The case becomes more serious when security logs reveal that a privileged application administrator, Ravi, used emergency access to view the investigation case shortly after Elena was recused. Ravi has no business reason to access the case. The case-management application is managed by his team, and the emergency role technically permits broad support access.

Ravi explains that he was investigating a performance issue. Ticket history confirms a genuine incident but does not explain why he opened Elena's case specifically. Further logs show that he searched for Meridian by name. Investigators now treat Ravi's activity as a separate insider-risk line rather than assuming he is part of Elena's conduct.

Relationship analysis finds that Ravi and Daniel previously worked at the same small technology firm, but the employment periods overlap only briefly. That is a weak contextual fact. The stronger evidence is access without apparent need, targeted search activity and subsequent deletion of a local support export. The central log still records the activity because audit data is stored outside the application administrator's control.

This is why protected logging matters. If administrators could rewrite the only record of their own actions, the investigation would depend on testimony rather than evidence.

Following the money without inventing a story

Investigators review Meridian payments but do not assume that money paid to a connected supplier is necessarily a bribe. They establish the contractual basis, invoices, delivery evidence, payment dates and destination accounts. Services were substantially delivered. Pricing is somewhat above one benchmark but within a range that other bidders could reasonably justify because the scope changed.

The new Meridian bank account belongs to Meridian itself, not Elena or Ravi. No bank payment directly reaches either employee. That finding weakens a simple kickback theory.

However, investigators discover from legally obtained financial-interest information that Elena acquired a minority interest in a private holding company owned by Daniel several months after the tender. The transaction needs careful analysis. It could represent an ordinary family investment. Timing alone does not prove the tender was corrupt. Legal and HR teams determine what evidence can lawfully be examined and what employment or criminal standards apply.

The investigation therefore maintains separate propositions: undisclosed family conflict, possible inappropriate influence over procurement, possible later financial benefit, and possible unauthorised case access by a technical insider. Each proposition has its own evidence and conclusion.

Decision and remediation

The bank ultimately substantiates that Elena breached conflict-disclosure and procurement-conduct requirements. It also finds evidence that she improperly influenced aspects of the tender. Whether the conduct meets a legal definition of bribery or another offence is referred to Legal and the relevant specialist teams under applicable law. The educational point is not the legal label; it is the quality of the evidence path.

Ravi's unauthorised case access is separately substantiated. The review does not establish that he altered the investigation, but his access breached privileged-access and confidentiality controls. Appropriate HR and disciplinary decisions follow the bank's local employment framework.

Meridian is not automatically labelled criminal. Procurement and Legal reassess the contract, ownership, delivery and supplier risk. The bank determines whether the relationship can continue under enhanced governance or should be terminated according to contractual and legal rights. Payments are reviewed on their own facts.

The most important remediation is structural. The bank integrates high-risk conflict mitigations with sourcing workflow so active recusals affect participation rights. Vendor onboarding gains a controlled employee-relationship check using proportionate data. Procurement exceptions involving recused employees require independent approval. Emergency case-management access becomes time-limited, ticket-bound and subject to immediate review. Support exports are moved to controlled storage. Senior procurement staff receive targeted conflict training based on the case themes, not on confidential individual facts.

A retrospective lookback checks other Meridian decisions and other tenders in which the same process weakness existed. That is essential: a confirmed case proves that a mechanism was possible. The bank should ask whether anyone else used it.

What a business analyst should take from the case

The first lesson is that policy state must become workflow state. A recusal recorded in one system but invisible to the tender platform is not reliably operational.

The second is that identity links need evidence quality. The address match started the review but did not justify action until the family relationship was verified.

The third is that technical privilege is part of the control boundary. The investigation application was confidential at the business layer but overexposed at the administrator layer.

The fourth is that historical reconstruction matters. Investigators needed the tender rules, employee role, declaration state, vendor ownership, permissions and bank-account details as they existed at each relevant date.

The fifth is that customer or vendor disposition is separate from employee disposition. An employee can breach policy without proving the counterparty committed wrongdoing, and a counterparty can present risk even if no employee breach is established.

Questions for a design review

A design team should be able to answer these questions before go-live:

1. How does an active recusal affect access and approval in connected business systems?
2. Can a conflicted manager approve the mitigation or see a restricted allegation?
3. Which identifiers join HR, IAM, procurement, customer and case data, and how are changes versioned?
4. What evidence does entity resolution show when it claims an employee-counterparty relationship?
5. Can administrators read or alter sensitive case data without independent logging?
6. What happens when emergency access is granted during an incident?
7. Can vendor bank-account changes be correlated with recent ownership, procurement or access events?
8. Can investigators reconstruct who knew what and when?
9. How are false relationship matches corrected without leaving unjustified employee flags?
10. What root-cause action is mandatory after a substantiated internal-threat case?

If the architecture cannot answer those questions, the policy may be sound while the control remains fragile.

References and further reading

These sources support the chapter's control principles. They do not create one universal legal rule. Banks must map obligations to the legal entity, employee population, product and jurisdiction involved.

• Basel Committee on Banking Supervision — Corporate governance principles for banks, consolidated framework — current Basel governance material covering conflicts of interest, internal controls, checks on discretion and segregation of duties in banks.
• Basel Committee on Banking Supervision — Compliance and the compliance function in banks, consolidated framework — addresses compliance independence, access to records and investigation of possible breaches.
• European Banking Authority — Guidelines on internal governance under CRD — EU prudential guidance covering conflicts affecting management bodies and staff; apply only within the relevant CRD/EU scope and national implementation.
• FATF — The FATF Recommendations — Recommendation 18 and its interpretive note provide the global AML/CFT framework for internal policies, controls, compliance arrangements, employee screening where appropriate, training and independent audit.
• FFIEC — BSA/AML Examination Manual: Assessing the BSA/AML Compliance Program, Internal Controls — U.S. banking examination guidance on responsibilities, dual controls, segregation of duties, information technology and escalation of control deficiencies.
• Wolfsberg Group — Anti-Bribery and Corruption Compliance Programme Guidance — bank-industry guidance on risk-based ABC programmes, employee accountability, confidential reporting, investigations, remediation and training.
• Wolfsberg Group — publication note for the 2023 ABC guidance — publication context and date for the Wolfsberg guidance used in this chapter.
• U.S. Department of Justice — Evaluation of Corporate Compliance Programs, September 2024 — U.S. prosecutorial evaluation guidance covering confidential reporting, investigations, autonomy and resources, incentives, discipline and continuous improvement; it is not a global banking rulebook.
• UK Government — Bribery Act 2010 guidance — official UK guidance on the Bribery Act and adequate procedures; use only for matters within UK legal scope.
• CISA — Insider Risk Self-Assessment Tool — U.S. cybersecurity and critical-infrastructure material useful for the security dimension of insider-risk programmes; it does not define bank conduct or bribery law.
• EUR-Lex — Directive (EU) 2019/1937 on the protection of persons who report breaches of Union law — EU whistleblower framework; operating requirements depend on scope and national transposition.