Unit 06 · Chapter 5 · 10 min read

Sponsor banks, vendors, and third-party risk

Keep accountability visible across the financial-service supply chain.

The vendor says the bank owns it. The bank says the platform runs it. The platform says the vendor automates it. A responsibility that travels in a circle is still a responsibility no one is performing.

Map responsibility beyond the contract title

Third-party relationships can cover technology, operations, customer contact, screening, and funds handling. Identify the actual work and the accountable entity for each duty. A service-level agreement measures performance; it does not necessarily transfer legal responsibility.

Create a responsibility matrix for normal work, exceptions, incidents, and termination. Include subcontractors where relevant. The person who can fix an outage may differ from the person who can authorize a customer remedy. Test the handoffs with a concrete case so gaps appear before a live incident.

A contract can allocate tasks, but the customer experience crosses the whole chain. A fintech may own the interface, a bank may hold funds, a processor may move messages, and another provider may perform identity checks. The operating map should show who can observe each failure, who can stop the affected action, who must communicate, and who can correct the records.

A responsibility matrix is useful only when the named teams can perform the work. Confirm access to the necessary data, service contacts, escalation authority, and reconciliation records. A partner can agree to investigate an issue yet lack the identifiers needed to locate it. Integration design should supply those identifiers before the first incident.

Map responsibility beyond the contract title Map responsibility beyond the contract title — the flow Follow the sequence. Define evidence and escalation. Function Identify the work performed Accountability Assign the responsible entity Handoff Define evidence and escalation — Follow the sequence. Define evidence and escalation. Chapter sources · Open image

Map responsibility beyond the contract title Map responsibility beyond the contract title — the distinction These concepts answer different questions. Read each definition in the context of the section. Operational provider Performs a task Accountable owner Retains the duty or decision authority — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Map responsibility beyond the contract title Responsibility example Fictional teaching record. Separate communication task. Responsibility example Illustrative data; not a real customer record or a prescribed policy. Screening vendor service Operational execution Disposition bank compliance Illustrative accountable role Customer update platform support Separate communication task A contract title does not resolve every handoff — Fictional teaching record. Separate communication task. Chapter sources · Open image

Map responsibility beyond the contract title Map responsibility beyond the contract title — control and failure modes A contract title does not resolve every handoff. The branches show why alternative designs fail. Control design Assign normal and exception responsibilities. A contract title does not resolve every handoff. Failure mode 1 Assume outsourcing transfers all duties. Responsibility can remain with the institution. avoid Failure mode 2 Ignore subcontractors. They can affect the service and data. avoid Failure mode 3 Use a contact list without authority mapping. People may be unable to make the needed decision. avoid — A contract title does not resolve every handoff. The branches show why alternative designs fail. Chapter sources · Open image

Perform risk-based due diligence

Vendor diligence should match the criticality and nature of the service. Assess security, resilience, financial condition, compliance support, data handling, and the ability to provide evidence. A low-cost service can still be critical if every payment depends on it.

Review what assurance reports cover and what they exclude. A report for one product or period may not cover the service you use today. Track unresolved findings and compensating controls. The purpose is to understand the dependency and decide whether it can be managed, not to collect certificates without reading their scope.

Perform risk-based due diligence Perform risk-based due diligence — the flow Follow the sequence. Accept conditions remediate or choose another path. Criticality Assess the consequence of failure Evidence Review relevant service assurance Decision Accept conditions remediate or choose another path — Follow the sequence. Accept conditions remediate or choose another path. Chapter sources · Open image

Perform risk-based due diligence Perform risk-based due diligence — the distinction These concepts answer different questions. Read each definition in the context of the section. Certificate exists Some assurance artifact is available Relevant assurance Scope period and findings match the service — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Perform risk-based due diligence Assurance review Fictional teaching record. Gap to resolve. Assurance review Illustrative data; not a real customer record or a prescribed policy. Report period last year Time limitation Covered service product A Scope limitation Used service product B Gap to resolve An artifact may not cover the actual dependency — Fictional teaching record. Gap to resolve. Chapter sources · Open image

Perform risk-based due diligence — control and failure modes

Control design

Check assurance scope and unresolved findings. An artifact may not cover the actual dependency.

Failure mode 1avoid: Approve from a logo page. Marketing is not control evidence.
Failure mode 2avoid: Rank risk only by contract price. Cheap services can be critical.
Failure mode 3avoid: Ignore old findings after renewal. The exposure may persist.

An artifact may not cover the actual dependency. The branches show why alternative designs fail. Chapter sources · Open image

Monitor the relationship in operation

Due diligence is a starting point. Monitor service health, data quality, incidents, complaints, control changes, and contractual performance. Define which changes require notice or review. A vendor can alter a model or subprocessor without changing the API shape.

Use your own outcome evidence where possible. Vendor uptime can be high while your integration receives incomplete records. Reconcile expected and received data, test support escalation, and review repeated exceptions. Keep the relationship owner accountable for unresolved issues rather than distributing them across unrelated tickets.

Monitor the relationship in operation Monitor the relationship in operation — the flow Follow the sequence. Use the contractual and operational path. Observe Measure actual service and data outcomes Review Assess changes and recurring issues Escalate Use the contractual and operational path — Follow the sequence. Use the contractual and operational path. Chapter sources · Open image

Monitor the relationship in operation Monitor the relationship in operation — the distinction These concepts answer different questions. Read each definition in the context of the section. Vendor uptime Provider service availability Integration quality Your workflow receives usable complete results — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Monitor the relationship in operation Partner monitoring Fictional teaching record. Uptime does not explain completeness. Partner monitoring Illustrative data; not a real customer record or a prescribed policy. Availability 99.9 percent Provider metric Missing identifiers 8 percent Your data-quality issue Action joint mapping review Uptime does not explain completeness Provider metrics can miss integration defects — Fictional teaching record. Uptime does not explain completeness. Chapter sources · Open image

Monitor the relationship in operation Monitor the relationship in operation — control and failure modes Provider metrics can miss integration defects. The branches show why alternative designs fail. Control design Measure the service as your product experiences it. Provider metrics can miss integration defects. Failure mode 1 Rely only on the status page. Data can be wrong while service is up. avoid Failure mode 2 Ignore silent model changes. Decision behavior can change. avoid Failure mode 3 Leave recurring issues scattered. Ownership and trend analysis are lost. avoid — Provider metrics can miss integration defects. The branches show why alternative designs fail. Chapter sources · Open image

Plan for failure and exit

A critical partner can fail, restrict service, change terms, or end the relationship. An exit plan should address data portability, customer obligations, funds, keys, notices, and operational capacity. A second contract is not a tested migration.

Define the minimum service needed during transition and the evidence required to reconcile balances. Test exports and recovery procedures before they are urgent. Avoid assuming every transaction can be rerouted to another bank without legal, contractual, and technical work. The plan should state which dependencies remain and how unresolved obligations will be handled.

Exit planning tests whether the business can continue to meet existing obligations after a relationship ends. It covers funds, records, open disputes, customer communication, credentials, and the ability to operate or transfer critical services. A replacement vendor does not automatically inherit the history required to resolve old cases. Define the export format, completeness checks, retention responsibilities, and transition sequence. The plan is strongest when a controlled test demonstrates that the receiving system can use the data, not merely download a file.

Plan for failure and exit Plan for failure and exit — the flow Follow the sequence. Verify continuity and remaining work. Prepare Define exit triggers and required assets Transfer Move data and obligations under approved arrangements Reconcile Verify continuity and remaining work — Follow the sequence. Verify continuity and remaining work. Chapter sources · Open image

Plan for failure and exit Plan for failure and exit — the distinction These concepts answer different questions. Read each definition in the context of the section. Backup vendor Another provider is named Executable exit Data authority capacity and tests support transition — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Plan for failure and exit Exit readiness Fictional teaching record. Plan needs an exercise. Exit readiness Illustrative data; not a real customer record or a prescribed policy. Data export available One requirement Balance mapping untested Critical gap Customer continuity unproven Plan needs an exercise A named alternative does not prove migration readiness — Fictional teaching record. Plan needs an exercise. Chapter sources · Open image

Plan for failure and exit Plan for failure and exit — control and failure modes A named alternative does not prove migration readiness. The branches show why alternative designs fail. Control design Test the exit with data and obligations. A named alternative does not prove migration readiness. Failure mode 1 Assume instant bank substitution. Authority and integration can differ. avoid Failure mode 2 Ignore pending disputes. Obligations outlive new sales. avoid Failure mode 3 Wait for termination to test exports. The provider may no longer be available. avoid — A named alternative does not prove migration readiness. The branches show why alternative designs fail. Chapter sources · Open image

Avoid false assurance in customer promises

Customer-facing statements about deposits, insurance, security, speed, and partner roles must reflect the actual product and applicable conditions. A fintech logo beside a bank logo does not explain where funds are held or what protection applies.

Review the complete customer journey: marketing, onboarding, balance screens, help text, and incident messages. Make relevant conditions understandable at the point they matter. Keep approved wording linked to the current product arrangement so a partner change triggers a content review. Accurate promises reduce both compliance risk and customer confusion.

Avoid false assurance in customer promises Avoid false assurance in customer promises — the flow Follow the sequence. Review wording when the product changes. Promise Identify the customer-facing claim Evidence Match it to the actual arrangement Maintain Review wording when the product changes — Follow the sequence. Review wording when the product changes. Chapter sources · Open image

Avoid false assurance in customer promises Avoid false assurance in customer promises — the distinction These concepts answer different questions. Read each definition in the context of the section. Partner relationship A firm works with a bank Customer protection Depends on the actual account and legal conditions — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Avoid false assurance in customer promises Claim review Fictional teaching record. Align message with behavior. Claim review Illustrative data; not a real customer record or a prescribed policy. Marketing instant access Customer promise Actual funds held pending review Conditional availability Correction clear status and conditions Align message with behavior One accurate disclaimer may not repair misleading screens — Fictional teaching record. Align message with behavior. Chapter sources · Open image

Avoid false assurance in customer promises Avoid false assurance in customer promises — control and failure modes One accurate disclaimer may not repair misleading screens. The branches show why alternative designs fail. Control design Verify claims across the whole customer journey. One accurate disclaimer may not repair misleading screens. Failure mode 1 Use bank logos as a complete explanation. The arrangement and conditions matter. avoid Failure mode 2 Keep old wording after a partner change. The claim can become false. avoid Failure mode 3 Promise unconditional access to restricted funds. The product cannot deliver that promise. avoid — One accurate disclaimer may not repair misleading screens. The branches show why alternative designs fail. Chapter sources · Open image

Chapter connections

This chapter builds on Privacy, payment data, and secure evidence. Use the glossary for terminology and risk mathematics for formulas and worked calculations.

Sources

Reviewed 2026-09-17