Textbook/Compliance & trust
Unit 06 · Chapter 5 · 15 min read

Sponsor banks, vendors, and third-party risk

Keep accountability visible across the financial-service supply chain.

The concept at a glance

Make the handoff accountable

A fictional matrix shows platform, bank, and processor roles for detecting a gap, stopping the flow, correcting records, and contacting customers. O denotes the coordination owner, D denotes a party doing work, and a dash means no assignment in this map. Operating roles do not transfer or determine legal responsibility.

Enlarge to read every label and explore the connections

A contract does not show who will act during a failure. An operating map makes coordination, execution, and evidence visible.

  1. Map normal work, exceptions, incidents, and exit.

  2. Name who can observe, stop, correct, and communicate.

  3. Test the handoff with a concrete failure case.

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

Map responsibility beyond the contract title — the flow
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
  1. FunctionIdentify the work performed
  2. AccountabilityAssign the responsible entity
  3. HandoffDefine evidence and escalation
Follow the sequence. Define evidence and escalation. Chapter sources · Open image

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.

Inside the mechanism. Map responsibilities by observable action: who collects evidence, decides, executes, communicates, corrects, and monitors. Contract titles can hide gaps between those steps. A partner may own a process while the fintech owns the customer interface that must explain its result. Test the real handoff with a concrete event and verify that the receiving team has both the information and authority to act.

A concrete example. The fintech, bank, processor, and vendor may each own part of the customer path. A contract assignment is useful only when the responsible team can observe and act. The case identifies 1,742 eligible records from a source population of 2,050. The required workflow completes for 1,690, but 25 completed records miss the illustrative internal target. Another 52 remain incomplete. Communication evidence covers 1,673 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.

When the assumption fails. Each party assumes another team owns an unresolved customer event. Map observation, authority, correction, communication, and escalation across the actual chain. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

The fintech, bank, processor, and vendor may each own part of the customer path. A contract assignment is useful only when the responsible team can observe and act.

Responsibility beyond contract labels: reference condition figure preview01Reference conditionResponsibility beyond contract labelsResponsibility beyond contract labels: failure and stress figure preview02Failure and stressResponsibility beyond contract labelsResponsibility beyond contract labels: controlled response figure preview03Controlled responseResponsibility beyond contract labels
Map responsibility beyond the contract title — the distinction
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
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
Responsibility example
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 educational excerpt / Not for execution

Responsibility example

Illustrative data; not a real customer record or a prescribed policy.

  1. Screeningvendor service

    Operational execution

  2. Dispositionbank compliance

    Illustrative accountable role

  3. Customer updateplatform 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 — control and failure modes
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
Control design

Assign normal and exception responsibilities. A contract title does not resolve every handoff.

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

Perform risk-based due diligence

Perform risk-based due diligence — the flow
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
  1. CriticalityAssess the consequence of failure
  2. EvidenceReview relevant service assurance
  3. DecisionAccept conditions remediate or choose another path
Follow the sequence. Accept conditions remediate or choose another path. Chapter sources · Open image

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.

Inside the mechanism. Due diligence should address the service the product will actually use and the consequences of its failure. Examine capability, control evidence, limitations, subcontracting dependencies, incident response, data access, and exit feasibility. A certification or questionnaire is one evidence item, not a complete conclusion. Keep unresolved conditions visible and tie approval to the operating assumptions that make the relationship acceptable.

A concrete example. The depth of review should reflect the activity, dependency, customer impact, and available evidence. A certification does not answer every operating question. The case identifies 703 eligible records from a source population of 890. The required workflow completes for 682, but 10 completed records miss the illustrative internal target. Another 21 remain incomplete. Communication evidence covers 675 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.

When the assumption fails. A vendor questionnaire is accepted without testing the service used by the product. Evaluate the relevant capability, limitations, control evidence, and failure or exit path. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

The depth of review should reflect the activity, dependency, customer impact, and available evidence. A certification does not answer every operating question.

Risk-based partner due diligence: reference condition figure preview01Reference conditionRisk-based partner due diligenceRisk-based partner due diligence: failure and stress figure preview02Failure and stressRisk-based partner due diligenceRisk-based partner due diligence: controlled response figure preview03Controlled responseRisk-based partner due diligence
Perform risk-based due diligence — the distinction
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
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
Assurance review
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 educational excerpt / Not for execution

Assurance review

Illustrative data; not a real customer record or a prescribed policy.

  1. Report periodlast year

    Time limitation

  2. Covered serviceproduct A

    Scope limitation

  3. Used serviceproduct 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
Perform risk-based due diligence Perform risk-based due diligence — control and failure modes An artifact may not cover the actual dependency. The branches show why alternative designs fail. Control design Check assurance scope and unresolved findings. An artifact may not cover the actual dependency. Failure mode 1 Approve from a logo page. Marketing is not control evidence. avoid Failure mode 2 Rank risk only by contract price. Cheap services can be critical. avoid Failure mode 3 Ignore old findings after renewal. The exposure may persist. avoid
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

Monitor the relationship in operation — the flow
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
  1. ObserveMeasure actual service and data outcomes
  2. ReviewAssess changes and recurring issues
  3. EscalateUse the contractual and operational path
Follow the sequence. Use the contractual and operational path. Chapter sources · Open image

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.

Inside the mechanism. Monitor business outcomes as well as uptime. Missing settlement records, delayed cases, stale screening data, and failed customer notices can occur while an API remains available. Define thresholds as internal operating decisions with owners and response paths. Material changes in the partner’s service or dependency chain should trigger review. Compare the actual service with the promise on which the product relies.

A concrete example. A service that passed onboarding can later change systems, capacity, subcontractors, or data quality. Ongoing monitoring needs the actual outcomes that matter to the product. The daily source population is 11,200 items, but 224 are outside the completed monitoring run. The included population creates 263 hits and 216 unique cases. With 38 cases already open and capacity for 230, the queue closes at 24. Coverage, duplicate work, and staffing are separate causes; reducing one number does not prove that the overall control improved.

When the assumption fails. Headline availability stays green while reconciliation and case delivery deteriorate. Track business-level service evidence, exceptions, changes, and accountable responses. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

A service that passed onboarding can later change systems, capacity, subcontractors, or data quality. Ongoing monitoring needs the actual outcomes that matter to the product.

Partner performance in operation: reference condition figure preview01Reference conditionPartner performance in operationPartner performance in operation: failure and stress figure preview02Failure and stressPartner performance in operationPartner performance in operation: controlled response figure preview03Controlled responsePartner performance in operation
Monitor the relationship in operation — the distinction
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
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
Partner monitoring
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 educational excerpt / Not for execution

Partner monitoring

Illustrative data; not a real customer record or a prescribed policy.

  1. Availability99.9 percent

    Provider metric

  2. Missing identifiers8 percent

    Your data-quality issue

  3. Actionjoint 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 — control and failure modes
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
Control design

Measure the service as your product experiences it. Provider metrics can miss integration defects.

Failure mode 1avoid
Rely only on the status page. Data can be wrong while service is up.
Failure mode 2avoid
Ignore silent model changes. Decision behavior can change.
Failure mode 3avoid
Leave recurring issues scattered. Ownership and trend analysis are lost.
Provider metrics can miss integration defects. The branches show why alternative designs fail. Chapter sources · Open image

Plan for failure and exit

Plan for failure and exit — the flow
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
  1. PrepareDefine exit triggers and required assets
  2. TransferMove data and obligations under approved arrangements
  3. ReconcileVerify continuity and remaining work
Follow the sequence. Verify continuity and remaining work. Chapter sources · Open image

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.

Inside the mechanism. An exit plan needs usable records, stable identifiers, open obligations, reconciliation history, and a tested receiving process. File export alone does not prove that another system can restore the service. Model the transition period, access rights, customer communication, and unresolved cases. Test recovery without assuming that the failing partner will provide perfect assistance at the moment it is most needed.

A concrete example. Replacing a critical partner requires usable records, stable identifiers, open-case history, and a transition sequence. Downloading a file is not the same as restoring the service. 250 intended requests generate 262 processing attempts under this retry assumption. Capacity is 310 attempts per interval, and the critical path consumes 150 ms of a 500 ms budget. The request-based SLO view observes 100 bad requests against an illustrative allowance of 100. These measurements must be connected to the financial effect and control evidence before declaring recovery.

When the assumption fails. The receiving system cannot interpret the exported customer and transaction history. Test data completeness, mappings, unresolved obligations, and restoration of critical operations. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

Replacing a critical partner requires usable records, stable identifiers, open-case history, and a transition sequence. Downloading a file is not the same as restoring the service.

Failure and exit readiness: reference condition figure preview01Reference conditionFailure and exit readinessFailure and exit readiness: failure and stress figure preview02Failure and stressFailure and exit readinessFailure and exit readiness: controlled response figure preview03Controlled responseFailure and exit readiness
Plan for failure and exit — the distinction
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
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
Exit readiness
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 educational excerpt / Not for execution

Exit readiness

Illustrative data; not a real customer record or a prescribed policy.

  1. Data exportavailable

    One requirement

  2. Balance mappinguntested

    Critical gap

  3. Customer continuityunproven

    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 — control and failure modes
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
Control design

Test the exit with data and obligations. A named alternative does not prove migration readiness.

Failure mode 1avoid
Assume instant bank substitution. Authority and integration can differ.
Failure mode 2avoid
Ignore pending disputes. Obligations outlive new sales.
Failure mode 3avoid
Wait for termination to test exports. The provider may no longer be available.
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

Avoid false assurance in customer promises — the flow
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
  1. PromiseIdentify the customer-facing claim
  2. EvidenceMatch it to the actual arrangement
  3. MaintainReview wording when the product changes
Follow the sequence. Review wording when the product changes. Chapter sources · Open image

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.

Inside the mechanism. Customer promises should match the actual account arrangement, funds status, service responsibility, and applicable protection. Avoid allowing a familiar partner brand to imply features the product does not have. Keep interface language and support guidance connected to authoritative product facts. A change in partner or funds flow can require a wording change as well as an integration change.

A concrete example. The interface should explain funds status and service responsibilities accurately. A familiar brand name can otherwise imply protection or availability the product does not provide. The case identifies 4,437 eligible records from a source population of 5,100. The required workflow completes for 4,304, but 65 completed records miss the illustrative internal target. Another 133 remain incomplete. Communication evidence covers 4,261 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.

When the assumption fails. A customer sees available funds when the underlying obligation is still pending or restricted. Connect customer wording to the actual account, funds state, and applicable product facts. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

The interface should explain funds status and service responsibilities accurately. A familiar brand name can otherwise imply protection or availability the product does not provide.

Accurate customer promises: reference condition figure preview01Reference conditionAccurate customer promisesAccurate customer promises: failure and stress figure preview02Failure and stressAccurate customer promisesAccurate customer promises: controlled response figure preview03Controlled responseAccurate customer promises
Avoid false assurance in customer promises — the distinction
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
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
Claim review
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 educational excerpt / Not for execution

Claim review

Illustrative data; not a real customer record or a prescribed policy.

  1. Marketinginstant access

    Customer promise

  2. Actual fundsheld pending review

    Conditional availability

  3. Correctionclear 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 — control and failure modes
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
Control design

Verify claims across the whole customer journey. One accurate disclaimer may not repair misleading screens.

Failure mode 1avoid
Use bank logos as a complete explanation. The arrangement and conditions matter.
Failure mode 2avoid
Keep old wording after a partner change. The claim can become false.
Failure mode 3avoid
Promise unconditional access to restricted funds. The product cannot deliver that promise.
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
  1. Federal Reserve SR 23-4: third-party relationships
  2. FTC: Safeguards Rule business guidance