Third-Party Risk Management (TPRM)

A bank can outsource an activity, buy a service, appoint an agent or depend on a fintech, but it cannot outsource the consequences of the relationship. That is the simplest useful way to think about third-party risk management. A third party may process transactions, introduce customers, sell products, perform collections, operate technology, provide local expertise, handle sensitive data or interact with public officials on the bank's behalf. If that relationship is poorly understood, the third party can become a route through which bribery, sanctions exposure, fraud, money laundering, customer harm, data leakage, operational failure or inaccurate books and records enter the bank.

TPRM is therefore much broader than procurement paperwork. The control objective is to understand who the third party is, why the bank needs it, what the third party will actually do, what risks the relationship creates, what evidence supports approval, what conditions must remain true during the relationship, and how the bank will detect and respond when those conditions change. The strongest programmes connect the commercial decision to the risk decision rather than allowing them to live in separate systems and separate teams.

This chapter focuses on the financial-crime dimension of TPRM, especially anti-bribery and corruption risk, while showing how it joins the bank's wider operational, compliance, security and resilience framework. It does not assume that every vendor is high risk or that every unusual intermediary is corrupt. Risk should be proportionate to the service, access, geography, compensation model, government touchpoints, ownership, subcontracting, customer impact and other facts. The point is not to make third-party relationships difficult. The point is to make important relationships explainable and controllable.

TPRM is not one thing

Banks use the phrase "third party" for many different relationships. A cloud provider hosting a payments platform, a local sales agent introducing corporate clients, a correspondent bank, a law firm, a call-centre provider, a cash-in-transit company, an outsourcing partner, a software vendor and a merchant-acquiring technology partner are all external organisations, but their risk profiles are not remotely the same. A useful TPRM model starts by asking what the third party can do, not merely what category procurement assigned to it.

A technology provider may create operational resilience, data-protection and cyber risk because it has privileged access to systems and customer data. A sales intermediary may create anti-bribery risk because it is paid a success fee and interacts with public-sector decision makers. A collections agent may create conduct risk because it communicates directly with vulnerable customers. A payment processor may create sanctions and AML risk because it transmits data or makes control decisions that affect transactions. A local corporate-services provider may create beneficial-ownership opacity or tax-integrity risk. A fintech partnership may combine several of those risks at once.

This is why a single vendor questionnaire is rarely sufficient. The bank needs a common lifecycle and governance framework, but the due-diligence questions, approval route, contract clauses, monitoring and testing should be tailored to the actual activity. The 2023 U.S. interagency guidance on third-party relationships makes the same proportionality point for banks within its supervisory perimeter: not all relationships have the same risk or criticality, and risk management should be commensurate with the bank's risk profile, complexity and the criticality of the activity. That is a supervisory principle for the covered U.S. institutions, not a universal legal rule for every bank in every country.

TPRM is also not the same as customer due diligence. A vendor supplying payroll software is not automatically a customer, and customer KYC procedures cannot simply be copied into supplier onboarding. However, some data disciplines overlap. If a third party is a legal entity, the bank may need to understand ownership and control, especially where bribery, sanctions, conflicts of interest or hidden public-official connections are plausible. FATF's beneficial-ownership standards are designed primarily for AML/CFT transparency of legal persons and arrangements; they provide a useful framework for understanding why reliable, current ownership information matters, but they do not by themselves define a universal third-party onboarding obligation.

Why financial-crime teams care about third parties

Third parties are attractive in misconduct schemes because they can create distance. A bribe paid directly from a bank employee to an official is comparatively easy to recognise as a control failure. A payment to a consultant who then pays a subcontractor connected to the official may look like a normal professional-services invoice. A suspicious transfer from a customer account can be monitored by transaction systems, while a questionable fee paid from accounts payable may never enter the same AML monitoring environment. A relationship manager may know the commercial story, procurement may know the contract, finance may know the invoice and compliance may know the adverse media, but no single team sees the full picture unless the control architecture joins those facts.

Anti-bribery enforcement guidance repeatedly focuses on intermediaries for that reason. In the United States, the Department of Justice's corporate compliance guidance asks whether a company applies risk-based and integrated processes to third parties, understands the business rationale for using them, performs appropriate diligence and manages them throughout the relationship. U.S. anti-bribery law and enforcement policy have their own jurisdictional scope and should not be treated as global law. In the United Kingdom, the Bribery Act framework places particular importance on persons associated with a commercial organisation and the adequacy of procedures designed to prevent bribery. The Ministry of Justice guidance identifies proportionate procedures, top-level commitment, risk assessment, due diligence, communication and monitoring/review as core principles. Again, applicability depends on the UK legal perimeter and facts.

The broader banking lesson is universal even where the law differs: a bank should know why a third party is being used and whether the relationship makes commercial and control sense. A small distributor charging 18% of contract value for vaguely described "market access" in a public-sector deal should not be treated exactly like a large software vendor charging a fixed subscription. A bank does not need proof of wrongdoing to ask for stronger evidence. The purpose of risk-based due diligence is to resolve uncertainty before value or authority is transferred.

The lifecycle: from business need to exit

A mature programme treats TPRM as a lifecycle rather than a one-time onboarding event. The U.S. interagency framework describes planning, due diligence and selection, contract negotiation, ongoing monitoring and termination. That sequence is useful beyond its direct supervisory scope because it forces the bank to consider both entry and exit. The 2026 EBA final Guidelines on third-party risk for non-ICT services similarly use a lifecycle approach for the institutions within their eventual scope, including risk assessment, due diligence, contracting, subcontracting, monitoring, documentation and exit strategies. As of 20 September 2026, those new EBA Guidelines are final but not yet applicable; they should not be presented as a current binding obligation before their application date.

The lifecycle begins before due diligence. The first question is not "has the vendor passed screening?" but why does the bank need this relationship? A documented business rationale should identify the service, sponsor, intended users, countries, customer or payment touchpoints, data or system access, expected fees, use of subcontractors and whether the third party will represent the bank externally. This helps determine inherent risk before controls are considered.

Next comes risk classification. Many banks use tiers such as low, medium, high or critical, but the label matters less than the logic. A risk assessment should distinguish operational criticality from financial-crime exposure. A cloud service may be operationally critical without meaningful bribery exposure. A small local agent may be non-critical to operations but high risk for bribery because it is paid contingent fees to influence a government-linked sales process. Combining all risk into one score can hide those differences. A better architecture records separate risk dimensions and then applies an approval policy to the combination.

Due diligence follows. The depth should be proportionate to the relationship. Basic checks may include legal existence, ownership, management, reputation, sanctions and PEP exposure where relevant, financial viability, licensing status, information-security capability and conflicts of interest. Higher-risk intermediaries may require deeper review of experience, qualifications, relationships with public officials, prior misconduct, litigation, subcontractors, fee structure, bank-account ownership, references and the plausibility of the proposed service. The bank should distinguish facts from assumptions and preserve the evidence used at the time of decision.

Approval should be explicit. A third party should not become "approved" merely because no system generated a red flag. The decision should state who approved, under which policy version, which risk tier applied, what conditions were imposed, when review is due and what unresolved issues were accepted. High-risk relationships may need independent compliance or legal review in addition to business approval. The business sponsor remains accountable for the commercial relationship even where specialist functions provide challenge.

Contracting then converts risk decisions into enforceable expectations. Contract clauses cannot prevent misconduct by themselves, but they establish rights and obligations that help the bank control the relationship. Depending on the risk, the contract may address scope of services, compensation, anti-bribery and sanctions obligations, compliance with applicable law, records, audit or access rights, training, subcontracting, data use, security, incident notification, regulatory cooperation, conflicts, termination and post-termination obligations. A clause that is never monitored is weaker than it appears on paper.

Activation should be a controlled event. The third party may need system access, payment setup, a supplier master record, API credentials, customer-facing permissions or authority to represent the bank. Those access decisions should rely on the approved relationship record rather than being created independently. If a relationship has not completed required due diligence, access and payment capability should not quietly bypass the TPRM process.

Ongoing monitoring keeps the relationship current. Monitoring should consider what could change: ownership, directors, beneficial owners, public-official connections, sanctions status, adverse media, licensing, security posture, financial condition, subcontractors, service scope, geography, fee model, bank account, complaints, incidents, audit findings or transaction patterns. Some changes require immediate event-driven review rather than waiting for the periodic renewal date.

Finally, termination is a control phase, not an administrative afterthought. The bank should revoke access, disable credentials, settle legitimate obligations, recover or destroy data where required, preserve records, manage customer transition, notify regulators where applicable, confirm subcontractor closure and update systems so the third party cannot continue to receive payments or act under obsolete authority.

Risk assessment that reflects the real relationship

Inherent risk is the exposure before considering mitigating controls. A practical assessment asks how the third party could cause harm if controls failed. Useful dimensions include the nature of the service, countries involved, access to customers or funds, data sensitivity, ability to create or approve transactions, public-sector interaction, compensation structure, use of cash, use of subcontractors, regulatory licences, ownership complexity, concentration risk, system dependency and whether the service supports a critical or important function.

For anti-bribery risk, several patterns deserve stronger questions. Success fees or unusually high commissions can create incentives that are difficult to explain. A third party recommended by a public official or customer decision maker creates a potential conflict that needs context. A newly formed company with little relevant experience may be legitimate, but the business rationale becomes more important. Requests to pay an unrelated entity or personal account weaken the link between contract and payment. Repeated use of vague invoices such as "consultancy services" can obscure whether work actually occurred. Subcontractors introduced after approval can defeat the original due diligence if they perform the sensitive activity.

None of these features proves bribery. They are risk indicators that alter the evidence burden. The control should move from signal to question, not from signal to accusation. A bank may resolve a high commission by showing specialist expertise, documented market rates and deliverables. A politically connected owner may be acceptable if the connection is understood, conflicts are managed and the service is legitimate. The purpose of escalation is to make uncertainty visible to the right decision maker.

Residual risk is what remains after controls and evidence are considered. A common mistake is to reduce residual risk mechanically because forms are complete. Controls should only reduce risk when they are relevant and credible. A signed anti-bribery certification is useful evidence of expectation, but it does not offset opaque ownership, implausible fees and missing service evidence by itself. A high-risk relationship may remain high risk even after enhanced due diligence; the decision may then be to accept with conditions, restructure, decline or exit.

Due diligence: evidence before comfort

Good due diligence answers four different questions: identity, capability, integrity and relationship logic. Identity asks whether the bank knows the legal entity, ownership and relevant controllers. Capability asks whether the third party can genuinely provide the proposed service. Integrity considers misconduct, sanctions, corruption, fraud, adverse regulatory findings or other concerns. Relationship logic asks why this particular third party, in this market, at this price, with this role, is commercially sensible.

Legal-entity evidence may come from official registries, constitutional documents, licences, tax records and reliable independent sources. Where ownership is complex, the bank may need to trace layers to natural persons or controllers, particularly if sanctions or corruption risk is relevant. The bank should store the source, retrieval date and relationship, not merely a copied name. Beneficial ownership can change after onboarding; point-in-time history matters when an investigator later asks who controlled the third party when a payment was made.

Screening is only one component. Sanctions screening should follow the bank's sanctions policy and applicable legal regimes; it should not be described as a universal 50% rule because ownership and control tests differ by jurisdiction. PEP screening can identify political exposure, but PEP status is not evidence of corruption and does not automatically mean the third party is unsuitable. Adverse media should be assessed for source quality, identity match, recency, seriousness and relevance. A useful due-diligence file records why a concern was cleared or escalated.

Capability can be tested through references, experience, staffing, licences, prior work, delivery plan and evidence of local presence. If the third party is being paid for access rather than expertise, that distinction should be visible. A consultant with no employees, no prior sector experience and a large success fee may still have a legitimate role, but the sponsor should be able to explain it. The more sensitive the role, the less acceptable vague commercial rationale becomes.

Integrity review also includes internal conflicts. Employees may have family, financial or prior-employment connections to vendors. A procurement manager may influence selection of a company owned by a relative. A relationship manager may push an intermediary because it helped win earlier deals. Conflict-of-interest declarations should be linked to the relationship record and refreshed when key people change.

Contracts and payment controls are part of TPRM

Many control failures happen after a third party has passed onboarding. The due-diligence file may be strong, but later invoices, new bank accounts, subcontractors and service changes can create a different risk profile. TPRM therefore needs to connect to contract management and accounts payable.

The contract should match the due-diligence story. If the approved role is "market research," invoices for "government liaison" should trigger review. If the third party was approved for one country, expansion into another high-risk jurisdiction should not occur through an informal email. If subcontracting was prohibited or subject to approval, payments to a newly introduced subcontractor require investigation before release.

Payment controls can test whether the beneficiary is the contracted entity, whether the bank account is in an expected name and country, whether the invoice relates to an approved purchase order or contract, whether the amount and fee basis are consistent, whether services were evidenced and whether approvals are current. Changes to settlement instructions are especially sensitive because fraud and corruption risks can overlap. Independent verification of bank-account changes helps prevent both supplier fraud and diversion of questionable payments.

Some third parties receive customer or transaction funds rather than ordinary supplier payments. In those models, the bank must map the money flow explicitly. Who is legally holding funds? Which accounts are used? Who can initiate transfers? Which screening and monitoring controls apply? Who investigates alerts? Which party reports suspicious activity where required? Which party communicates with customers? Contract wording cannot substitute for a clear operating model.

Ongoing monitoring and event-driven review

Periodic review is useful but insufficient because risk does not change on an annual schedule. A mature programme defines trigger events. Examples include a change in beneficial ownership, new directors, a new public-official connection, sanctions-list update, material adverse media, licence suspension, data breach, fraud event, customer complaint spike, control-test failure, new subcontractor, acquisition, new geography, change in service scope, material fee change or request to change the payment account.

The event should route to the right review. A low-risk software vendor changing a director may not require the same response as a government-facing agent whose beneficial owner becomes a senior official. Automation can help identify and route events, but policy needs to define materiality and escalation. The system should preserve the original event, the data before and after the change, the reviewer, decision and effective date.

Monitoring should also look at performance against the contract and risk controls. Service-level breaches, unresolved audit issues, repeated exceptions, security incidents and poor remediation can show that a relationship is no longer within risk appetite. For intermediaries, payment patterns may matter: repeated round-dollar fees, unexplained expense reimbursements, payment to third countries, accelerated invoices near contract award, split invoices below approval limits or rapid requests after a customer decision may warrant contextual review.

It is dangerous to treat such patterns as automated proof of misconduct. The analytic layer should create reviewable hypotheses. Investigators need business context, contract terms, invoice data, payment history, relationship ownership, communications and relevant external information. The outcome may be clear, require additional evidence, impose conditions, suspend payment, suspend the third party, launch a formal investigation or exit the relationship.

Investigations and case handling

A third-party case often begins outside the TPRM platform. A whistleblower allegation, accounts-payable exception, sanctions alert, audit finding, customer complaint, adverse-media update or employee conflict disclosure may be the trigger. The bank needs a common case identifier so evidence from procurement, compliance, HR, legal, payments and finance can be connected without uncontrolled copying.

The investigator should reconstruct the relationship chronologically. What was known at onboarding? Which ownership structure was recorded? Which approvals existed? What did the contract permit? When did bank details change? What services were invoiced? What payments were made? What monitoring alerts were generated? Who approved exceptions? Which legal or policy rules applied at each point? A chronology is often more useful than a static snapshot because it reveals whether risk emerged gradually or whether controls were bypassed at a specific moment.

Investigation outcomes should be separated from legal conclusions. A bank may find insufficient evidence to substantiate bribery but still identify a control failure, such as missing approvals, weak service evidence or unmanaged subcontractors. Remediation can therefore include payment recovery, contract amendment, enhanced monitoring, retraining, system control changes, disciplinary action, third-party suspension or exit. Where suspicious-activity reporting, sanctions reporting, law-enforcement notification or regulatory notification may apply, local legal requirements and confidentiality restrictions must govern the decision.

Data and systems: build an evidence chain, not a collection of tools

TPRM often spans too many systems: sourcing, procurement, supplier master, contract management, corporate registry data, screening, adverse media, identity and access management, accounts payable, payment processing, case management, issue management and management information. The architecture problem is not simply integration. It is identity resolution and traceability.

The bank needs a stable third-party identifier that survives name changes and links the legal entity to owners, contracts, risk assessments, bank accounts, services, users, invoices, payments, cases and issues. If the same company appears under slightly different names in procurement and screening systems, monitoring may fail. If a supplier-master change is not linked to TPRM, a new bank account can bypass risk review. If ownership data is overwritten rather than versioned, investigators lose historical truth.

Useful data fields include legal name, registration number, jurisdiction, tax identifier where appropriate, business type, ownership and control relationships with effective dates, key directors, business sponsor, service, risk dimensions, criticality, countries, public-sector touchpoints, screening results, due-diligence sources, contract dates, subcontractors, approvals, conditions, review date, payment accounts, incidents, cases and exit status. Not every field belongs in one database, but the relationships need to be queryable.

Workflow should enforce sequencing. A high-risk third party should not become payment-enabled before mandatory approval. A contract should not be marked active if required due diligence has expired. A user should not receive privileged access because an IT ticket was approved while the third-party relationship is suspended. Exceptions should be explicit, time-bound and attributable to an authorised owner.

Audit logs matter. The bank should preserve who changed the risk rating, why an alert was cleared, which ownership source was used, which approver accepted an exception and what version of policy applied. A good question for system design is: could an independent reviewer reconstruct the relationship two years later without relying on someone's memory? If the answer is no, the evidence model is incomplete.

Governance and decision rights

The business sponsor owns the reason for the relationship and should remain accountable for whether the service is needed and performed. Procurement or a TPRM operations team may coordinate onboarding and evidence collection. Financial-crime compliance challenges bribery, sanctions, AML or fraud exposure. Legal interprets applicable law and contractual rights. Information security and operational risk assess technology and resilience. Finance and accounts payable control supplier setup and payments. Internal audit provides independent assurance rather than operating the first-line control.

Clear decision rights prevent two common failures. The first is approval by diffusion, where several teams review a relationship but no one owns the final decision. The second is compliance substitution, where the business assumes that compliance approval means commercial ownership has transferred. A RACI can help, but governance should be built into workflow states and permissions rather than existing only in a policy appendix.

Risk acceptance should be specific. If due diligence cannot verify one ownership layer, the decision should identify that uncertainty and why it is acceptable or what condition mitigates it. Senior approval should not be a ceremonial click. The approver needs enough context to understand what is being accepted.

Management information should show more than volume. Useful measures include overdue high-risk reviews, due diligence exceptions, unresolved audit issues, third parties with expired licences, material ownership changes, overdue remediation, subcontractor concentration, payment-account changes, high-risk fees, open investigations, repeat findings and termination progress. Metrics should support decisions rather than reward rapid closure.

Jurisdiction matters

TPRM programmes often fail when a global policy turns one regulator's guidance into a worldwide legal statement. The 2023 U.S. interagency guidance is supervisory guidance for banks within the OCC, Federal Reserve and FDIC perimeter described by the agencies. The 2024 community-bank guide is explicitly a resource and says it is not a checklist, a substitute for the interagency guidance or a safe harbour.

The UK Bribery Act and Ministry of Justice guidance are relevant where the UK legal nexus applies. They should inform anti-bribery control design but should not be presented as though every third-party relationship worldwide is governed by section 7. The U.S. FCPA similarly has specific jurisdictional elements and should be analysed with legal support rather than inferred from currency or payment routing alone.

In the EU, DORA governs ICT third-party risk for in-scope financial entities, while the EBA's newly finalised September 2026 Guidelines address non-ICT third-party services within their scope. The EBA page currently states that the final non-ICT Guidelines are not yet applicable and that they will repeal the older outsourcing guidelines once applicable. A bank designing for future compliance can prepare now, but training material should preserve that effective-date distinction.

Local requirements may also govern outsourcing, data localisation, bank secrecy, regulator access, critical services, customer-data processing, payment agents, licensing, anti-bribery controls, sanctions and record retention. A global platform should therefore store jurisdiction, legal entity, service and effective dates so local rules can be mapped without hard-coding a single global threshold.

What business analysts, architects and testers should demand

A BA should be able to trace each control requirement to a risk and a decision. "Screen vendors" is not sufficient. A stronger requirement states which parties are screened, against which data sets or policy categories, at what lifecycle points, how ownership is treated, how potential matches route to review, what blocks activation, what evidence is stored and how rescreening occurs after data changes.

Architects should design for entity identity, versioned ownership, event triggers and cross-system state. The system should know that the entity approved in TPRM is the same entity receiving payment and the same entity whose users receive system access. The design should tolerate incomplete external data without silently converting uncertainty into a clean status.

Testers need positive, negative and failure-mode scenarios. A clean low-risk supplier should move without unnecessary friction. A high-risk agent with opaque ownership should trigger enhanced review. A sanctions false positive should be resolvable without permanently blocking the relationship. A material owner change after onboarding should create event-driven review. A supplier-bank-account change should require independent verification. A system outage should not allow mandatory controls to be bypassed without a governed fallback. A subcontractor introduced after approval should follow policy rather than inherit the parent's status automatically.

Testing should also include temporal questions. What happens when a sanctions list changes while an invoice is pending? What if a contract expires but payment instructions remain active? What if a relationship moves from low to high risk after a country change? Can the bank reproduce the old ownership graph for a payment made six months earlier? Can it identify all third parties affected by a newly designated beneficial owner? Those questions expose architecture weaknesses that happy-path onboarding tests miss.

Practical example: the small agent with a large fee

A corporate bank plans to enter a new market and appoints a local business-development agent. The agent is a small company with two employees and proposes a 7% success fee for introductions to state-owned enterprises. The company is legally registered and not on a sanctions list. A simple screening-only process might therefore return "clear."

A risk-based process asks more. Who owns the agent? What relevant experience does it have? Why is a success fee appropriate? Who introduced it to the bank? Will it interact with public officials? Can it appoint sub-agents? What deliverables show work performed? Where will payments be made? Are expenses reimbursable? What controls apply before invoices are paid?

Due diligence identifies that one minority owner is the sibling of a senior official at a state-owned customer. That fact does not prove corruption, but it materially changes the risk. The bank can escalate to compliance and legal, document the relationship, test whether the official can influence the procurement, change the commercial model, restrict subcontracting, require detailed service evidence and strengthen payment approval. The bank may decide the risk can be managed, or it may decide that the relationship is unnecessary given safer alternatives.

Six months later, the agent asks for an urgent payment to a different account in another country and submits a vague invoice immediately after a contract award. The original due diligence should not be treated as permanent clearance. The account change, timing and invoice are new facts. The payment can be held for verification, the case linked to the original relationship, and investigators can reconstruct the chronology before a decision is made.

The lesson is not that small agents are inherently risky. It is that the commercial story, ownership, role, compensation, behaviour and payment evidence must continue to make sense together.

Failure modes that repeatedly weaken programmes

One failure mode is treating onboarding completion as risk management. The relationship is approved once, but ownership, bank accounts, services and subcontractors change without event-driven review. Another is excessive centralisation of evidence without clear ownership: thousands of documents exist, but no one can explain the final decision. A third is screening dependence, where the absence of sanctions or adverse-media hits is mistaken for proof that the business rationale and integrity risk are acceptable.

A fourth failure is disconnected payment systems. The third party may be suspended in TPRM while accounts payable continues to release invoices because supplier status is not synchronised. A fifth is contract drift, where the third party begins performing activities outside the approved scope. A sixth is weak termination: access remains active, data is retained unnecessarily, standing payment instructions persist, and business teams continue informal contact after the formal relationship ends.

A final failure is poor proportionality. Some banks respond to regulatory pressure by making every relationship equally burdensome. That creates backlogs and encourages workarounds. The better response is stronger differentiation: low-risk relationships move efficiently, while scarce specialist attention focuses on relationships that can materially affect customers, funds, data, regulatory obligations, public-sector interactions or the bank's ability to operate.

The mental model to keep

A useful TPRM programme can be reduced to five questions:

1. Why are we using this third party and what exactly can it do?
2. Who owns or controls it, and what facts make the relationship higher or lower risk?
3. What must be true before we approve, pay, connect or give access?
4. What changes would make us review, restrict, investigate or exit?
5. Can we reconstruct the decision and evidence later?

When those questions are joined across business, procurement, compliance, finance, technology and assurance, TPRM becomes a real banking control rather than a vendor questionnaire.

Operational deep dive: how TPRM works when the bank is under pressure

The base chapter described the lifecycle. This deep dive focuses on the difficult operating questions that appear after a policy has been written: how to classify a relationship without hiding risk inside one score, how to handle incomplete ownership evidence, how to manage subcontractors, what should trigger re-review, and how a bank can run TPRM at scale without turning the process into either a rubber stamp or a permanent queue.

Start with the service, not the supplier label

The same legal entity can create different risk depending on the service it performs. A global consulting firm providing general market research may be low financial-crime risk for one engagement but materially higher risk if another team appoints it to interact with public authorities, manage licensing or identify government counterparties. A payment technology company can be an ordinary software vendor in one relationship and an embedded-finance partner with access to customer transactions in another.

This means the relationship record should separate the legal entity from the engagement or service. Entity-level information such as ownership, incorporation and sanctions screening can be reused where still current, but service-level facts such as scope, countries, data access, customer contact, government touchpoints, fee model and subcontracting must be assessed for each engagement. Otherwise a low-risk approval for one service can accidentally become a passport for a completely different activity.

A useful data model therefore has at least three linked objects: third-party entity, engagement, and service or capability. Large banks may add contracts, facilities, products, subcontractors and legal entities as separate objects. The exact schema can vary, but one principle should not: a reviewer must know which facts apply globally to the supplier and which apply only to a particular engagement.

Inherent risk and criticality should not be collapsed

Operational criticality and financial-crime exposure answer different questions. Criticality asks what happens to the bank if the service fails. Financial-crime risk asks how the relationship could facilitate misconduct or weaken a control. A payroll provider may be critical to employee operations but low in bribery risk. A small public-sector introducer may be operationally non-critical yet high in anti-bribery risk. A payment processor may be both.

If a bank combines all dimensions into one averaged score, material risk can disappear. A "medium" overall score may hide a very high sanctions exposure offset mathematically by low cyber risk. Better designs retain risk dimensions separately and let policy determine which combinations require enhanced due diligence or specialist approval.

Inherent risk factors can include:

• ability to handle customer or bank funds;
• access to sensitive data or privileged systems;
• authority to represent the bank or negotiate externally;
• interaction with public officials or state-owned enterprises;
• use of success fees, commissions, rebates or expense reimbursement;
• countries of operation and payment;
• licensing or regulatory dependency;
• ownership complexity and public-official connections;
• use of subcontractors or agents;
• customer-facing authority;
• control over transaction data, screening or financial-crime decisions;
• operational criticality and concentration.

The risk methodology should explain why each factor matters. A field that cannot change due diligence, approval, monitoring or governance is often just data collection.

Risk tiering should change the work

A tier is useful only if it changes what happens next. Low-risk relationships may need basic legal-entity verification, sanctions screening where policy requires it, financial viability checks and standard contracting. Higher-risk relationships may require ownership tracing, enhanced adverse-media review, public-official analysis, source validation, specialist approval, fee benchmarking, references, detailed service evidence, subcontractor review and more frequent monitoring.

Tiering should also affect contract clauses, access controls and payment gates. A high-risk government-facing intermediary should not have the same payment workflow as an office-supplies vendor. If policy requires compliance approval before payment, the payment system or supplier master should consume that status rather than relying on a manually circulated email.

A practical weakness appears when the assessment produces a high rating but downstream systems do nothing differently. The bank can claim to have a risk-based methodology while still operating a uniform control. Testing should therefore prove that the risk score changes the actual workflow.

What to do when ownership is incomplete

Ownership data is often messy. Registers may be incomplete, nominee arrangements may obscure control, and private companies may provide inconsistent charts. The correct response is not to invent certainty. The bank should record what is known, what source supports it, what is missing, what additional steps were taken and whether the remaining uncertainty is acceptable for the relationship.

For anti-bribery and sanctions risk, control can matter as much as formal ownership. A person may influence a company through voting arrangements, appointment rights, family relationships, financing or management even without a large direct shareholding. Legal tests differ by regime, so TPRM should not encode one global control threshold as universal law. The system should be able to store both percentage ownership and other control relationships, with evidence and effective dates.

Where reliable beneficial-ownership information is unavailable, escalation should be proportional to the risk. A low-risk commodity supplier may not justify an extensive investigation. A high-fee agent interacting with public officials should carry a much higher evidence burden. The decision is not "ownership verified yes/no" in isolation; it is whether the bank has enough confidence to accept the risk of the specific engagement.

Public officials, PEPs and state-owned enterprises

TPRM teams often confuse three related but different ideas: politically exposed persons, public officials for anti-bribery purposes, and employees of state-owned or state-controlled enterprises. The definitions and legal consequences vary by jurisdiction and policy.

A PEP screening result is a risk signal, not a bribery conclusion. An individual can be politically exposed without being a public official for a particular anti-bribery rule, and a person who is relevant under an anti-bribery law may not appear on a PEP database. Third-party due diligence should therefore combine screening with contextual questions about government ownership, decision-making authority, family or business relationships and the role the third party will perform.

The bank should also avoid overreaction. Legitimate businesses frequently have government-linked owners or customers. The objective is to understand and manage conflicts and influence risk, not to exclude relationships solely because public-sector connections exist.

Subcontractors and fourth parties

A relationship can look well controlled at first-party level and become opaque one layer down. A vendor may subcontract customer support, payment processing, data hosting, sales, local representation or collections. If the subcontractor performs the activity that created the original risk, the bank cannot safely assume the primary vendor's due diligence is enough.

The contract should define when subcontracting is permitted, what notification or approval is required and which controls flow down. TPRM should record material subcontractors and the services they perform. For critical or important arrangements, regulatory frameworks may impose additional expectations on subcontracting and exit planning. The applicable rule depends on jurisdiction and service type.

The operational challenge is change detection. A supplier can introduce a new subcontractor after onboarding. The bank should receive notification where required and route the change through risk assessment. Monitoring can also use invoice, access or network data to identify entities not present in the approved chain.

Third-party bank-account changes deserve special control

Supplier-account changes are a classic point where fraud, corruption and process weakness overlap. A legitimate vendor can change banks, but an urgent request to pay a new account in another name or jurisdiction should not be accepted solely because the request came from a familiar email address.

Strong control separates request, verification and execution. The change should be independently verified through a trusted contact or approved channel, checked against entity and contract data, recorded with effective date, and subject to enhanced review where the risk profile warrants it. High-risk relationships may need compliance review when the new account introduces an unexpected country or unrelated beneficiary.

This control protects against business-email compromise and invoice fraud while also making it harder to redirect legitimate contract payments into concealed channels.

Event-driven review should be designed, not improvised

A periodic review date creates a useful safety net, but the most important risk changes often happen between reviews. The bank should define events that automatically create a review task. Those events can originate from internal systems or external data.

Examples include ownership or control changes, sanctions or PEP updates, material adverse media, licence changes, regulatory actions, new countries, contract amendments, service expansion, customer complaints, fraud events, security incidents, unresolved audit findings, new subcontractors, changes to payment accounts or unusual invoice behaviour. The event should carry its source and timestamp so the reviewer can distinguish a current fact from stale data.

The response should depend on materiality. Some events simply refresh the file. Others require suspension of new business, blocking of access, payment hold, legal advice or investigation. A decision matrix should be configurable by risk type and jurisdiction rather than embedded in code without governance.

Ongoing monitoring is not continuous surveillance of everything

Monitoring should be purposeful. A low-risk office supplier does not need the same surveillance as an agent handling government tenders. The monitoring plan should follow the risk assessment and the contractual obligations.

For a technology provider, monitoring may focus on security, resilience, incidents, service performance and subcontractors. For a sales intermediary, it may focus on ownership changes, government connections, fee patterns, invoices, expenses and complaints. For a payment partner, it may include sanctions-control performance, alert backlogs, transaction-quality metrics, customer complaints, fraud losses and regulatory incidents.

The design question is always: what change would make us decide differently? If a metric cannot trigger a review, restriction, remediation or governance action, its value should be challenged.

When TPRM meets AML, sanctions and fraud

Third-party risk is often split across control functions. An outsourcing team may assess resilience, procurement may assess financial viability, sanctions teams may screen names, AML teams may assess transaction controls, fraud teams may review losses and anti-bribery teams may assess intermediaries. Those specialisms are necessary, but the relationship needs a consolidated view of unresolved issues.

A fintech partner onboarding merchants illustrates the problem. Procurement can approve the contract, information security can approve the API, and compliance can approve a policy document. But if the partner's actual KYC rejection rate collapses, fraud rises and sanctions alerts age beyond service levels, the bank needs one governance route capable of restricting the relationship. Control ownership can remain distributed while relationship-level risk is aggregated.

Remediation must change the relationship

A finding is not remediated because an action plan exists. The bank should identify root cause, owner, due date, interim control and evidence of closure. Material issues may require payment restrictions, access limits, enhanced monitoring, new contractual rights or temporary suspension while remediation proceeds.

Repeated extensions are themselves a risk signal. Management information should distinguish overdue remediation by severity and show whether residual risk remains within appetite. If the third party cannot or will not remediate, exit should be a real option rather than a theoretical contract clause.

Exit planning begins before exit

Critical relationships are hardest to terminate when the bank has never considered how to replace them. Exit planning should identify data return or destruction, access revocation, customer communication, continuity arrangements, outstanding payments, regulatory notifications, record preservation and dependencies on subcontractors. For technology or payment services, migration can take months; concentration and portability therefore matter at onboarding.

For a financial-crime-sensitive intermediary, exit may also need investigative controls. The bank should preserve evidence, stop authority to represent the bank, disable payment instructions, review pending invoices and determine whether past activity requires lookback or reporting. Termination should not destroy the audit trail.

The operating standard

A strong TPRM file does not need to be enormous. It needs to answer the right questions with evidence. An independent reviewer should be able to see the commercial rationale, inherent risk, due diligence, ownership, screening, approval, contract, payment setup, monitoring, material changes, issues and final outcome in one coherent history.

That is the difference between collecting vendor documents and managing third-party risk.

Advanced practice: architecture, controls and testing for third-party risk

This section translates TPRM into delivery requirements. It is written for teams that need to design workflows, data, interfaces and controls rather than simply describe policy. The core design principle is that the bank must be able to connect a third-party legal entity to the exact engagement, contract, risk assessment, access, bank account, invoice, payment, monitoring event and case that affected a decision.

Build around a stable third-party identity

Names are weak identifiers. Legal names change, trading names vary and supplier systems often abbreviate entities. The architecture should use a stable internal third-party identifier linked to reliable external identifiers such as registration numbers and jurisdictions. Engagements, contracts and services should have their own identifiers so one supplier can support several activities without sharing one undifferentiated risk status.

The entity master should preserve name history, registration data, legal form, country of incorporation, status, known owners and controllers, directors, relevant licences and screening identifiers. Ownership relationships need effective dates. If the entity changes ownership on 1 June, investigators should still be able to reconstruct who controlled it on 31 May.

A relationship graph is often more useful than a flat table. It can connect parent companies, beneficial owners, directors, subcontractors, bank employees with disclosed conflicts, customer counterparties and public officials. The graph does not make legal conclusions automatically; it helps reviewers see connections that deserve contextual analysis.

Separate facts, scores and decisions

Systems often blur three different data types. A fact is something observed, such as incorporation country, percentage ownership or a sanctions-screening result. A score is a modelled interpretation, such as high geography risk. A decision is an authorised outcome, such as approve with conditions. These should not overwrite one another.

The system should retain source, timestamp and confidence for facts; model version for scores; and approver, rationale, policy version and conditions for decisions. This separation makes change manageable. When a country-risk model changes, the bank can recalculate scores without rewriting historical facts. When policy changes, old approvals remain reconstructable under the policy that existed at the time.

Model workflow states explicitly

A third-party engagement may move through states such as proposed, under inherent-risk assessment, due diligence in progress, specialist review, approved, approved with conditions, active, restricted, remediation, suspended, terminating and closed. Each transition should have entry criteria, permissions and downstream effects.

For example, moving from approved to active may require a signed contract, complete mandatory conditions, verified payment account and required security approval. Suspension may automatically stop new purchase orders or privileged access. Termination may trigger credential revocation and data-return tasks. The workflow should not rely on users remembering these consequences manually.

Exceptions need their own lifecycle. An exception should record the control being waived, reason, compensating control, approver, expiry and renewal rules. Permanent exceptions with no expiry often become undocumented alternative policies.

Link TPRM to accounts payable

One of the most valuable integrations is between TPRM and supplier payments. The supplier master should consume approved legal-entity and bank-account data. A new payment account should create a controlled change event rather than simply replacing the previous value. High-risk changes may need independent verification and compliance review before payment release.

Invoice data can support monitoring. The bank can compare invoice descriptions with approved service scope, fees with contract terms, beneficiary accounts with authorised accounts, country with expected geography and timing with commercial events. Analytics can flag unusual patterns, but the output should be a review signal rather than an automatic allegation.

A useful payment linkage contains third-party ID, engagement ID, contract ID, invoice ID, payment ID and beneficiary account. This allows an investigator to retrieve all payments for a specific engagement even if the supplier has several unrelated contracts.

Link TPRM to identity and access management

Third parties often receive physical or logical access. Access should depend on relationship status, service and role. A contractor should not retain access after the engagement expires because the HR or IAM system did not receive the termination event.

Joiner, mover and leaver controls should consume TPRM data where relevant. Privileged access may require stronger approval and shorter review cycles. Changes in employer, subcontractor or service scope should trigger access reassessment. Testing should verify that suspension or termination propagates promptly and that emergency access has its own evidence trail.

Screening architecture should support connected parties

Screening may apply to the third party, relevant owners, controllers, directors or other connected persons depending on policy and risk. The architecture needs to distinguish a name match from a confirmed identity match and a confirmed identity match from a legal consequence. A PEP hit, sanctions match and adverse-media result are different risk signals and should not be collapsed into one generic flag.

List updates and ownership changes should create rescreening where policy requires it. Historical screening results should remain linked to the list version and data seen at the time. This is essential when an investigator asks whether a party was designated before or after a payment.

Capture subcontractors as relationships, not free text

Free-text subcontractor fields are difficult to screen, monitor and report. Material subcontractors should be entity records linked to the primary third party and engagement. The link should show the service performed, country, start and end dates, approval status and whether the subcontractor can further delegate.

This enables questions such as: Which active critical services depend on the same subcontractor? Which approved agents use an entity that has just been sanctioned? Which relationships rely on a subcontractor in a country newly subject to restrictions? Without structured links, these questions become manual exercises during a crisis.

Design event-driven monitoring

Monitoring architecture should ingest events rather than wait for scheduled reviews. Events can come from company registries, screening vendors, adverse-media services, security systems, incident platforms, procurement, finance, contract management, customer complaints or manual disclosures.

Each event should carry a type, source, timestamp, affected entity, old and new value where relevant, materiality and routing result. Rules determine whether the event is logged, creates a task, blocks activity or escalates. Those rules need version control and approval because they affect business outcomes.

A useful design separates detection from disposition. Detection says something changed. Disposition decides whether the change matters and what action follows. That separation allows rules to become more sensitive without automatically causing inappropriate restrictions.

Evidence lineage is part of the product

An audit trail should answer: what data did the reviewer see, where did it come from, when was it obtained, who changed it, which rule fired, who approved the decision and what happened afterwards? Screenshots alone are poor evidence because they lose structure, source and effective date.

Evidence objects should include source URI or system, retrieval timestamp, document type, version or checksum where feasible, subject, reviewer notes and retention classification. If external data is licensed and cannot be stored indefinitely, the bank should preserve enough metadata to evidence what informed the decision while complying with contractual and privacy restrictions.

Rule versioning and effective dates

Third-party policies evolve. Sanctions regimes change, country-risk ratings change, regulators issue new guidance and business risk appetite moves. The platform should use effective-dated rules so a decision can be reproduced under the rule version that applied.

This matters especially in multinational banks. One jurisdiction may require regulator notification for an outsourcing arrangement while another does not. A global rule engine should map legal entity, jurisdiction, service and date to the relevant obligation rather than assume the strictest rule automatically applies everywhere. Applying a stricter internal policy globally can be a deliberate choice, but it should be labelled as policy rather than law.

Test the control as a chain

Component testing is not enough. A screening service can pass its own tests while the end-to-end control fails because ownership data never reaches it. Accounts payable can validate bank accounts while still paying a suspended third party because status is not synchronised. End-to-end tests should therefore follow realistic relationship journeys.

A positive onboarding test can use a high-risk intermediary with a public-official connection, complex ownership and contingent fee. The expected result may be enhanced due diligence, specialist review and conditional approval rather than automatic rejection. The test should prove that all required evidence and approvals exist before activation.

A negative test should use a low-risk supplier with complete evidence and no material risk signals. The expected result is efficient processing without unnecessary enhanced review. Good TPRM is not a system that makes every relationship difficult.

An event-driven test can change the beneficial owner after activation. The expected result should show rescreening, risk reassessment and appropriate routing while preserving historical ownership. Another test can change the supplier bank account to an unrelated entity in a new country and verify independent validation before payment.

Failure-mode testing

Controls behave differently during outages. If the screening vendor is unavailable, does onboarding stop, use a documented fallback or allow temporary approval? If the company registry API fails, is stale data clearly marked? If the TPRM platform cannot send status to accounts payable, are payments held or does the bank unknowingly operate without a control?

Fallback behaviour should be approved before the outage. A degraded mode should specify which relationships can proceed, what compensating checks apply, how exceptions are logged, who can approve and how retrospective review occurs. High-risk relationships may require a hard stop even when lower-risk work can continue.

Capacity failure matters too. A surge in sanctions updates or adverse media can create thousands of review tasks. Testing should examine queue prioritisation, service levels, ageing and escalation. A technically available control can still fail if human review capacity is overwhelmed.

Evasion and abuse testing

Teams should test how easily users or third parties can bypass controls. Can a sponsor split one engagement into several low-value contracts to avoid enhanced review? Can a user create a duplicate supplier under a slightly different name? Can a subcontractor be entered only in free text? Can invoice descriptions be changed without review? Can payment instructions be altered after approval?

These are not hypothetical software bugs; they are predictable workarounds when controls create friction. Red-team or control-abuse testing should identify paths around policy thresholds and close them without making legitimate business impossible.

Quality assurance and case sampling

First-line QA can verify completeness and procedure adherence. Second-line monitoring should challenge whether decisions are reasonable and policy is effective. Independent audit should assess governance and control design rather than simply repeat file checks.

Sampling should be risk-based and include both approved and declined relationships, high-risk approvals, exceptions, expired reviews, material bank-account changes, ownership changes, subcontractors and terminations. Sampling only clean completed files gives false comfort.

QA findings should feed back into training, forms, rules and data design. If reviewers repeatedly miss public-official relationships because the form asks only whether the third party is a PEP, the answer is not more reminders; the data question itself needs improvement.

Useful management information

Management information should answer whether exposure is controlled. Examples include high-risk relationships by business and geography, critical services by concentration, overdue reviews, open high-severity findings, unresolved ownership gaps, pending bank-account changes, sanctions or PEP escalations, unapproved subcontractors, expired licences, repeat incidents, payment exceptions, remediation ageing and exit progress.

Trend matters more than a single number. A rising backlog may signal capacity stress. Falling alert volumes may reflect improved quality or a broken feed. A high approval rate may reflect a healthy portfolio or weak challenge. Metrics should be interpreted with context.

Acceptance criteria for a bank-grade implementation

A TPRM capability should not be accepted merely because screens and workflows exist. At minimum, the bank should be able to demonstrate that:

• one legal entity can support multiple separately risk-assessed engagements;
• ownership and connected-party relationships are effective-dated and historically reconstructable;
• risk dimensions remain visible rather than being hidden in one average score;
• mandatory controls actually change workflow for higher-risk relationships;
• material changes create event-driven review;
• payment and access systems consume active relationship status where required;
• exceptions are approved, time-bound and reportable;
• subcontractors can be identified and linked;
• investigations can retrieve contract, invoice, payment and approval evidence;
• rules and policy versions are auditable;
• termination revokes access and payment capability and preserves records;
• outages and queue surges have tested fallback behaviour.

If those outcomes cannot be demonstrated, the programme may have a TPRM application but not yet a reliable TPRM control.

Practice close: review questions, acceptance criteria and control challenges

Use this section to test whether a TPRM design is operationally credible. The goal is not to memorise a checklist. It is to be able to inspect a relationship, challenge weak evidence and translate the risk into buildable controls.

Relationship review questions

Before approval, a reviewer should be able to answer the following in plain language:

Business rationale. Why is this third party needed? What will it actually do? Why was it selected? Is the proposed compensation understandable for the service?

Entity and ownership. Which legal entity is being contracted? Where is it registered? Who owns or controls it? Are material ownership gaps documented rather than hidden behind a clean status?

Activity and access. Will the third party handle money, customer data, systems, credentials, screening decisions, complaints, collections or public-sector interactions? Can it bind or represent the bank?

Geography. Which countries are relevant to incorporation, service delivery, customers, payment and subcontracting? Which local legal or regulatory overlays apply?

Integrity. Are sanctions, PEP, adverse-media, regulatory or conflict signals relevant? If a signal exists, has identity and context been resolved before a conclusion is reached?

Subcontracting. Can the third party delegate? Which subcontractors are material? How will the bank learn about changes?

Contract. Does the contract reflect the approved activity, risk controls, audit/access rights, notification duties, recordkeeping, subcontracting conditions and exit rights?

Payment. Is the beneficiary the contracted entity? Are fees and invoices consistent with the scope? How are bank-account changes verified? Which payment patterns require review?

Monitoring. What events trigger re-review? Who owns the review? What can be restricted while an issue is unresolved?

Exit. How will access, data, payments, customer dependencies and evidence be handled if the relationship ends?

BA acceptance criteria

A business analyst should reject vague requirements such as "perform vendor due diligence" or "monitor high-risk suppliers." Buildable requirements specify trigger, data, decision, owner and evidence.

Examples of stronger acceptance criteria include:

1. When a new engagement is created, the system assigns a unique engagement identifier linked to the third-party legal entity and business sponsor.
2. Risk assessment stores financial-crime, operational, technology, conduct and criticality dimensions separately and preserves the methodology version.
3. If policy classifies an engagement as high anti-bribery risk, activation cannot occur until required specialist approval is recorded.
4. Ownership relationships store owner, relationship type, percentage where known, source, effective date and end date.
5. A material ownership change creates an event-driven review without overwriting historical ownership.
6. Supplier payment accounts are linked to the approved legal entity. New or changed accounts require independent verification before use.
7. An unapproved beneficiary cannot be selected for payment merely because the commercial sponsor requests urgency.
8. Material subcontractors are stored as linked entities with service, geography and approval status.
9. Suspension of a relationship propagates to the downstream systems defined by policy, such as new purchase orders, payment release or privileged access.
10. Exceptions record control, rationale, approver, compensating control, start date and expiry.
11. Reviewers can retrieve the evidence set and policy/rule version used for any historical decision.
12. Termination triggers access revocation, data-handling tasks, payment closure and record-preservation actions.

Test pack: positive scenarios

A positive test demonstrates that the control catches a risk pattern and routes it correctly.

High-risk intermediary. Create a consultant with contingent fees, government-facing activity and a PEP-related owner. The expected outcome is enhanced review and appropriate escalation, not automatic rejection solely because a PEP connection exists.

Ownership change. Approve a third party and later replace a beneficial owner with a newly sanctioned person. The expected outcome should follow the bank's applicable sanctions policy, preserve the old ownership state and create the required decision path.

Bank-account change. Change an approved beneficiary account to an unrelated company in another country. Verify that payment cannot proceed without the required independent checks and approvals.

Subcontractor introduction. Add a subcontractor after approval to perform customer onboarding. Verify that the relationship is reassessed and that access is not inherited automatically from the primary vendor.

Scope expansion. Change a low-risk software vendor's role so it begins making customer eligibility decisions. The risk assessment and contract review should reopen because the activity changed materially.

Test pack: negative scenarios

Negative tests prove that legitimate activity can proceed without unnecessary friction.

Ordinary supplier. A well-established local supplier with simple fixed fees, no sensitive access and transparent ownership should complete basic review efficiently.

Legitimate bank change. A supplier moves its operating account to another bank in the same legal name and country. Independent verification succeeds. The system should update the record without forcing an unrelated high-risk investigation.

False-positive screening. A director shares a common name with a listed person but date of birth, nationality and other identifiers clearly differ. The reviewer should be able to resolve the match with evidence and preserve the rationale.

Expected subcontractor. A pre-approved hosting subcontractor begins service on the agreed date. The system should recognise the existing approval rather than create duplicate escalations.

Failure-mode tests

A mature programme tests the control when supporting services fail.

If a screening provider is unavailable, the system should follow the approved fallback rather than silently mark checks complete. If a company registry cannot be reached, stale data should be visible. If the TPRM platform cannot update accounts payable, the bank should know whether payments are held, manually controlled or allowed under a documented exception.

Queue stress also needs testing. A major sanctions update, cyber event or external data refresh may generate many review tasks at once. The bank should verify risk-based prioritisation, ageing alerts, escalation and management visibility. A control can fail through capacity even when its technology remains online.

Evasion tests

Attempt to bypass the programme deliberately:

• split one high-risk engagement into smaller contracts to avoid a threshold;
• create a duplicate supplier with altered spelling;
• put a subcontractor only in free-text notes;
• change the invoice beneficiary after approval;
• mark a government-facing activity as generic consulting;
• renew an expired contract without refreshing due diligence;
• leave third-party access active after termination;
• reuse an old approval for a new country or service.

A bank-grade system should either prevent these paths or make them visible for review.

What good evidence looks like

A defensible file should show facts and reasoning, not only attachments. It should state the trigger, evidence sources, risk assessment, unresolved questions, reviewer analysis, approval decision, conditions, contract alignment, monitoring plan and later changes.

For a screening match, the record should show why identity matched or did not match. For ownership, it should show source and effective date. For a high fee, it should show how commercial reasonableness was assessed. For an exception, it should show who accepted the risk and for how long.

Common weak answers

"The vendor passed screening" is weak because screening covers only part of TPRM.

"The contract has anti-bribery wording" is weak if the relationship's actual behaviour is not monitored.

"The business owns the risk" is incomplete if the bank has no independent challenge for material financial-crime exposure.

"Compliance approved" is incomplete if the commercial sponsor believes responsibility has transferred.

"We review annually" is weak if material ownership or account changes can occur the day after review.

"The supplier is globally reputable" is weak if the specific engagement uses an unusual agent, subcontractor or fee structure.

Final learner check

A learner should be able to explain these distinctions without looking them up:

• third-party entity versus engagement;
• inherent risk versus residual risk;
• operational criticality versus anti-bribery risk;
• screening result versus risk decision;
• PEP connection versus evidence of corruption;
• periodic review versus event-driven review;
• contract clause versus operating control;
• primary third party versus subcontractor;
• approval versus permanent clearance;
• termination date versus complete exit.

The practical standard is simple: the bank should know who it is relying on, what that party is allowed to do, why the relationship remains acceptable, and what evidence proves the answer at the relevant point in time.

Masterclass case: the market-entry agent, the hidden connection and the urgent payment

This case is fictional but built from recurring control patterns seen in third-party and anti-bribery risk. It is designed to show how a relationship that looks ordinary at onboarding can become materially different when ownership, public-sector interaction, subcontracting and payment behaviour are connected over time.

The business proposal

Northshore Bank, a fictional multinational bank, wants to expand cash-management services in Country R. The local corporate-banking team proposes appointing Delta Market Advisory, a small consulting company, to identify prospective corporate customers, arrange meetings and explain local procurement practices. The business sponsor says Delta has strong local relationships and could accelerate entry into the market.

Delta proposes a modest monthly retainer plus a 6% success fee on first-year revenue generated from customers it introduces. It has been operating for three years, has four employees and is not listed in the bank's existing supplier database. The relationship is not operationally critical; if Delta fails, the bank can continue operating. But the inherent anti-bribery risk is elevated because Delta will introduce the bank to state-owned enterprises and may interact with officials during tender processes.

The TPRM platform therefore routes the engagement to enhanced due diligence rather than treating it as an ordinary consultancy.

Due diligence does not find a prohibition, but it finds questions

Legal-entity checks confirm Delta is incorporated and active. Screening finds no sanctions matches. Adverse-media searches do not identify proven misconduct. At first glance the result could be called clean.

Ownership review provides more context. Sixty percent is owned by Delta's managing director. Twenty percent is held by an investment vehicle, and the remaining twenty percent is owned by the managing director's sister. Independent sources show that the sister's spouse is a senior procurement executive at a state-owned logistics company that the business team has identified as a priority client.

That connection is not evidence of bribery and does not automatically prohibit the relationship. It is, however, directly relevant to the bank's risk assessment. The due-diligence reviewer records the relationship rather than clearing the file simply because no one is a sanctions target.

The commercial review also questions the success fee. Six percent of first-year revenue could become significant for a large mandate. Delta's proposal describes "facilitation of market access" but provides little detail on deliverables. The bank asks for a clearer statement of work, fee justification and confirmation of whether Delta will communicate with public officials or customer procurement staff.

Delta responds that it will organise introductions, provide market intelligence and advise on local business etiquette. It says it will not make payments on the bank's behalf and will not appoint sub-agents without written approval. The bank negotiates a lower capped fee, detailed deliverables, anti-bribery representations, audit rights, recordkeeping obligations, approval before subcontracting and a requirement to disclose conflicts involving public officials or customer decision makers.

The approval is conditional, not binary

Compliance does not label Delta "safe." It records that the relationship is higher risk but can proceed under conditions. Legal confirms the contract language and jurisdictional analysis. The business sponsor accepts responsibility for verifying deliverables. Accounts payable is instructed that invoices need both business evidence and enhanced approval. Delta's bank account is verified in its own legal name in Country R.

The TPRM record stores the owner relationship, the family connection, the fee cap, approval conditions and review date. The bank also creates an event-driven trigger for ownership changes, new subcontractors and payment-account changes.

This is important: the approval is a point-in-time decision based on known facts. It is not a permanent certificate that everything Delta does later is acceptable.

Six months later, the pattern changes

Delta introduces Northshore to the state-owned logistics company. The bank enters a competitive tender. Two weeks before the tender decision, Delta sends an invoice labelled "strategic advisory and government relations support." The wording is outside the original statement of work, which explicitly avoided government-relations activity.

The invoice is also unusually large. It includes a reimbursable "local facilitation expense" with no supporting receipt. The business sponsor asks accounts payable to process it quickly because the tender decision is close.

At the same time, Delta requests that the invoice be paid to a new bank account in Country S, held by an entity called Meridian Services Ltd. Delta says Meridian is a treasury affiliate used for international settlements.

Any one of these facts might have an innocent explanation. Together they create a materially different picture: changed service description, timing near a public-sector tender, unsupported expense, urgent business pressure and payment to an unapproved third party in another country.

The payment control becomes the investigation trigger

Because the payment platform is linked to TPRM, the beneficiary mismatch creates a hold. Accounts payable cannot simply update the supplier bank account. The request is routed to the TPRM team and financial-crime compliance.

The investigator starts with chronology rather than accusation. The case pulls the original due-diligence record, ownership graph, contract, approval conditions, invoices, payment history and sponsor communications. The original file shows that Delta promised not to subcontract without written approval and that Meridian was not disclosed.

The investigator asks Delta to explain Meridian's role, ownership and services. Delta says Meridian provides "regional support" but initially resists providing ownership details. A registry search shows Meridian was incorporated four months earlier. One director previously worked for a company controlled by a relative of a local public official, but the link is indirect and does not establish wrongdoing.

The bank asks for the underlying service agreement, proof of work, beneficial-ownership information and explanation of the facilitation expense. Delta then states that Meridian arranged "protocol support" for meetings with public-sector representatives. This was outside the approved scope.

Decision rights matter under commercial pressure

The relationship manager argues that delaying payment could damage the tender. That is precisely why governance is needed. Commercial urgency cannot itself determine a financial-crime outcome.

The business sponsor confirms that the extra service was not formally approved. Procurement confirms there is no amendment. Compliance identifies unresolved anti-bribery concerns. Legal advises on applicable contractual rights and relevant anti-bribery obligations. Accounts payable keeps the payment on hold. Senior management is informed because the tender is material.

The bank does not need to prove a criminal offence before enforcing its own contract and risk controls. It can refuse to pay an unapproved entity where service evidence is inadequate and can suspend Delta from further activity while the facts are investigated.

The investigation outcome

Further review finds no reliable evidence that Northshore funds were paid to an official. The bank therefore does not state that bribery occurred. However, the evidence does establish several control and contractual problems: Delta expanded the service without approval, used an undisclosed subcontractor, requested payment to an unrelated legal entity, submitted an inadequately supported expense and created a conflict with the approved scope.

Northshore terminates Delta's authority to make introductions on its behalf and rejects the unsupported invoice. It reviews previous Delta payments for similar descriptions, confirms that earlier invoices matched the contracted entity and approved account, and assesses whether any regulatory or suspicious-activity reporting is required under the relevant local rules. Those reporting decisions are made by the responsible legal and compliance teams; they are not inferred automatically from the TPRM case.

The bank also examines its own control failures. The business team had informally discussed broader "government relations" support with Delta before the invoice arrived, but the conversation never triggered a contract-change workflow. The sponsor had also pushed accounts payable for urgency without recognising the new beneficiary as a control issue. Remediation therefore includes training, improved change triggers and a stronger rule that third-party payment-beneficiary changes cannot be approved by the commercial sponsor alone.

What the architecture contributed

The outcome depended on several systems working together. The TPRM platform stored Delta's approved legal entity, bank account, scope and conditions. Contract management stored the no-subcontracting condition. Accounts payable compared the requested beneficiary with approved supplier data. The case platform retrieved the point-in-time ownership and prior approvals. Without those links, the urgent invoice might have looked like an isolated finance request rather than a change to a high-risk relationship.

This illustrates why TPRM should not be a document repository. A bank needs relationship state that downstream controls can consume.

What would have gone wrong in a weak programme

A weak programme might have produced a different sequence. Procurement would have completed onboarding and emailed a PDF approval. Six months later, accounts payable would have received new bank details and updated the supplier record. The compliance team would not know the contract scope changed. The ownership information would still show the original date but no event trigger. The payment could be made before anyone connected the facts.

Another weak design would overreact and automatically terminate Delta as soon as the family connection was identified. That would also be poor risk management. The connection required enhanced understanding, not an unsupported accusation. Proportionality means the bank can distinguish manageable risk from unacceptable risk and document why.

BA and testing lessons from the case

A BA can derive concrete requirements from this scenario. The approved beneficiary account must be linked to the third-party record. A new beneficiary must create a change event. The workflow must distinguish the commercial sponsor from the independent verifier. Material contract-scope changes must trigger reassessment. High-risk third parties cannot introduce subcontractors without the required approval. Payment holds need reason codes and escalation routes. Historical ownership and approval evidence must remain retrievable.

Testing can then reproduce the journey. Start with a valid high-risk approval. Add an unapproved subcontractor. Change the payment beneficiary. Submit a vague invoice. Verify that the correct controls trigger and that users cannot bypass them through a lower-risk supplier workflow. Then test the opposite: a legitimate bank-account change for a low-risk supplier should be independently verified and completed without unnecessary escalation.

The central lesson

The most important fact in the case was not a name on a list. It was the change in the relationship story. The entity, service, subcontractor, invoice, beneficiary, timing and commercial pressure stopped fitting the original approval.

Good TPRM is designed to detect that drift. It allows banks to use third parties confidently while making it difficult for important changes to disappear between procurement, compliance, finance and the business.

References and further reading

The chapter uses the following public, first-party sources. Jurisdiction-specific material should be read within the legal and supervisory perimeter stated by the issuing authority.

Banking third-party risk

• Office of the Comptroller of the Currency, Board of Governors of the Federal Reserve System and Federal Deposit Insurance Corporation, Interagency Guidance on Third-Party Relationships: Risk Management, 6 June 2023: https://www.occ.gov/news-issuances/bulletins/2023/bulletin-2023-17.html
• Federal Deposit Insurance Corporation, Federal Reserve and OCC, Third-Party Risk Management: A Guide for Community Banks, 3 May 2024: https://www.fdic.gov/news/financial-institution-letters/2024/third-party-risk-management-guide-community-banks
• Federal Deposit Insurance Corporation, Third-Party Relationships resource centre: https://www.fdic.gov/banker-resource-center/third-party-relationships

European third-party risk

• European Banking Authority, Guidelines on third party risk management. The September 2026 final report on non-ICT services is currently marked not yet applicable: https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/internal-governance/guidelines-third-party-risk-management
• European Banking Authority, The EBA publishes its final Guidelines on the management of third-party risk, 18 September 2026: https://www.eba.europa.eu/publications-and-media/press-releases/eba-publishes-its-final-guidelines-management-third-party-risk-delivering-more-proportionate-and

Anti-bribery and corruption controls

• UK Ministry of Justice, Bribery Act 2010 guidance, updated 22 January 2025: https://www.gov.uk/government/publications/bribery-act-2010-guidance
• UK legislation, Bribery Act 2010: https://www.legislation.gov.uk/ukpga/2010/23/contents
• U.S. Department of Justice, Criminal Division, Compliance resources, including the Evaluation of Corporate Compliance Programs: https://www.justice.gov/criminal/criminal-fraud/compliance
• U.S. Department of Justice and U.S. Securities and Exchange Commission, A Resource Guide to the U.S. Foreign Corrupt Practices Act: https://www.justice.gov/criminal/criminal-fraud/fcpa-resource-guide
• OECD, Fighting foreign bribery: https://www.oecd.org/en/topics/fighting-foreign-bribery.html
• OECD, 2021 Anti-Bribery Recommendation: https://www.oecd.org/en/about/news/announcements/2021/12/high-level-statement-on-the-2021-anti-bribery-recommendation.html
• United Nations Office on Drugs and Crime, Business Integrity Portal: https://businessintegrity.unodc.org/

Ownership transparency

• Financial Action Task Force, Guidance on Beneficial Ownership of Legal Persons, 10 March 2023: https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Guidance-Beneficial-Ownership-Legal-Persons.html
• Financial Action Task Force, Guidance on Beneficial Ownership and Transparency of Legal Arrangements, 11 March 2024: https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Guidance-Beneficial-Ownership-Transparency-Legal-Arrangements.html

These sources establish useful control principles, but they do not create one universal TPRM law. A production bank must map requirements to its legal entities, jurisdictions, services, regulatory perimeter and effective dates.