Third-party risk management software and fintech partner oversight software answer two different questions, and a bank that owns one often assumes it has answered both. A general TPRM platform tracks the paperwork of a relationship: questionnaires, contracts, due-diligence files, renewal dates. Fintech Partner Oversight tests the relationship's actual weekly output — the loans a partner funded, the notices it sent, the complaints it received, the ads it is running — against the bank's own rules. Neither replaces the other; a bank that only has the first has never actually looked at a loan. The examples below come from fictional sample data in the solution: a sponsor bank, Brannock Valley Bank, and its partner Fernquill.
Two layers, two very different inputs
100%
of one partner’s weekly loan decisions tested against 24 rules, loan by loan
0
of those 24 tests a questionnaire can answer on its own
6
file types read every week: tapes, notices, complaints, ads, screening, findings
What a general TPRM platform actually checks
A third-party risk management platform's core unit of work is the questionnaire: a due-diligence form a partner fills out, attested to, and updates on a renewal cycle, alongside the contract, the SOC report, insurance certificates and whatever else due diligence requires before a relationship starts and periodically after. These platforms are built to track whether that paperwork exists, is current, and has been reviewed — a real and necessary job, and one the FDIC's guide for community banks treats as foundational: "due diligence is the process by which a community bank assesses, before entering into a third-party relationship, a particular third party's ability to perform the activity as expected" and to comply with applicable law.
What a questionnaire cannot do is look inside the relationship once it is running. A due-diligence form answered honestly in January says nothing about whether February's loans were priced correctly, whether March's decline notices gave the right reason, or whether April's ad campaign makes a claim the file cannot support. That is not a flaw in TPRM software; it is outside what a questionnaire was built to ask.
What fintech partner oversight checks instead
Fintech Partner Oversight starts where the questionnaire stops: the partner's actual weekly activity. Six agents read six kinds of file — the loan tape, adverse action notices, the complaint log, live marketing, OFAC screening results, and the findings themselves — and test each one against rules the bank wrote: the program's pricing grid, rate caps, the approved model list, Regulation B's notice requirements, the advertising rules a partner agreed to follow. On the sample week, that meant testing all 4,918 of one partner's decisions, not a sample, and all 3,576 of its adverse action notices.
Two layers of oversight, stacked
Third-party risk management
The relationship: questionnaires, contracts, due-diligence files, SOC reports, renewal dates. Answers: should we have this partner, and have they attested to what we require?
Loan-level testing
The output: the tape, the notices, the complaints, the ads. Answers: is this partner's actual activity, this week, inside the rules we agreed on?
The six agents and the single thing each one may never do are built entirely around this layer: none of them reads a questionnaire or a contract, and none of them decides whether the bank should have the partner in the first place. That decision, and the paperwork behind it, stays with whatever process — TPRM software or otherwise — already governs onboarding.
Where the two layers meet: due diligence vs. ongoing testing
The interagency guidance on third-party relationships lists the typical monitoring activities as "(1) review of reports regarding the third party's performance and the effectiveness of its controls; (2) periodic visits and meetings with third-party representatives to discuss performance and operational issues; and (3) regular testing of the banking organization's controls that manage risks from its third-party relationships, particularly when supporting higher-risk activities, including critical activities." It then adds the sentence that matters most for a lending partner: "In certain circumstances, based on risk, a banking organization may also perform direct testing of the third party's own controls."
That list names both layers. Reviewing a partner's reports and meeting its people is what a TPRM platform's workflow organises well. Testing controls, and directly testing the partner's own, is the loan-level layer, and a report about a partner's self-described performance cannot substitute for it. A partner that decides thousands of applications a week under the bank's charter is the plain case of a higher-risk activity.
The five stages of a partner relationship, and which layer covers each
The interagency guidance organises third-party risk management into a five-stage life cycle: planning, due diligence and third-party selection, contract negotiation, ongoing monitoring, and termination. Reading a TPRM platform and a loan-level tool against those stages is the quickest way to see where each belongs, and where a bank with only one of them has a hole.
The interagency life cycle, stage by stage: questionnaire layer against testing layer
| Stage | What the questionnaire layer holds | What the testing layer adds |
|---|---|---|
| 1. Planning | The business case, the risk assessment and the approval to look for a partner | Nothing yet: there is no partner activity to test |
| 2. Due diligence and selection | Questionnaires, financials, SOC reports, policies, references | A replay of the partner’s historical tape, if it will share one, tested against the proposed program rules |
| 3. Contract negotiation | The program agreement, its pricing grid and change-notice clauses, data-access and audit rights | The rules the weekly tests will enforce, taken from that agreement |
| 4. Ongoing monitoring | Renewal questionnaires, attestations, periodic reports and meetings | Every loan, notice, complaint and ad tested each week, with dated evidence |
| 5. Termination | Exit plan, transfer of records and customer communications | A final reconciliation of the portfolio and open findings before the relationship ends |
Stage three is where the layers depend on each other most. The FDIC's March 2024 supervisory highlights list two contract terms it has seen banks use to manage partner fair lending risk: the bank's "right to access data and information, including lending criteria, in a timely manner," and its "right to approve changes in processes and systems that affect work performed by the third-party service provider on the bank's behalf before implementation." A TPRM platform can confirm the clauses are in the signed agreement. Only a testing layer can show, each week, that the partner's data arrived and that no unapproved change reached production.
A due-diligence answer against a tested finding, same risk
What a TPRM questionnaire says: "Yes, we price within our approved program grid," attested at onboarding and each renewal.
What loan-level testing shows: 212 loans funded above the grid this week, all decided under a credit model version the bank had not approved.
What a TPRM questionnaire says: "Yes, our notices comply with Regulation B," attested annually.
What loan-level testing shows: 412 of 3,576 notices this week carried a reason the decision did not actually use.
What a TPRM questionnaire says: "All creatives are reviewed before launch," attested at onboarding.
What loan-level testing shows: One live ad, seen 1.2 million times, not in the approved library and missing a required rate disclosure.
What a TPRM questionnaire says: "Complaints are logged and resolved within SLA," attested annually.
What loan-level testing shows: Complaint volume rising for four straight weeks on one specific issue, with three CFPB responses already past the 15-day clock.
Can a TPRM platform test loan-level data at all?
Generally, no, not as a native capability, because loan-level testing requires reading a different kind of input — a tape of thousands of individual decisions, each tested against a program's own pricing and underwriting rules — than a TPRM platform's questionnaire-and-document model is built around. Some platforms can ingest a file as an attachment to a due-diligence record, but attaching a tape is not the same as testing every row of it against the bank's actual program grid, rate caps and approved model list, the way a purpose-built loan tape tester does.
A bank that wants both capabilities in practice usually needs two systems talking to each other, or a TPRM platform calling out to a loan-level tool as its testing layer — not a single piece of software quietly doing both jobs, because the two require fundamentally different inputs and different rules engines underneath.
What examiners ask for that a questionnaire cannot produce
An examiner reviewing fintech partner oversight does not stop at "show me the due-diligence file." The FDIC's Consumer Compliance Supervisory Highlights of March 2024 describe exactly this gap in a 2023 finding: an institution whose weaknesses meant "the institution was unable to access or produce complete and accurate credit transaction records from third-party lenders, which demonstrated a critical internal control and information system deficiency" — a finding about the loan-level layer, which no amount of complete, current due-diligence paperwork would have prevented.
What an exam pack needs that a questionnaire alone cannot supply
What fills a pack like this is dated evidence that specific tests ran, on specific weeks, against specific decisions — exactly what a loan-level tool produces and a questionnaire does not, because a questionnaire's evidence is an attestation, not a test result.
Do you need both, and in what order?
Yes, and due diligence comes first, logically if not always administratively. A bank onboarding a new fintech partner needs the TPRM layer's work done before the relationship starts — the risk assessment, the contract review, the due-diligence file — because loan-level testing has nothing to test against until a program agreement and a credit policy exist to test the loans against. The Cross River Bank consent order's remediation required exactly this ordering going forward: a New Third-Party Risk Assessment "for the proposed New Third Party" before any new relationship could proceed.
Once the relationship is live, the order reverses in importance, if not in sequence: due diligence becomes a periodic renewal exercise, while loan-level testing becomes the thing that runs every week and actually tells the bank what is happening. A bank that keeps investing in due-diligence tooling while leaving ongoing testing at a quarterly sample of a few dozen loans has built the first layer well and left the second one where it has always been.
What happens to a TPRM finding with no loan-level evidence behind it
A due-diligence questionnaire can surface a real concern — a partner's attested controls look thin, a contract clause is missing, an audit is overdue — but without loan-level evidence behind it, that concern stays a paper finding: real on the page, unverified against what the partner is actually doing. The reverse is equally true. A loan-level finding, such as 212 loans priced above the grid, is strongest when it can be tied back to a due-diligence record — in this case, the program agreement's own change-notice clause, which the unapproved model change violated.
The strongest findings cite both layers: what the contract required, and what the tested data shows actually happened. A bank running only one layer can usually produce half of that sentence.
How to tell which layer a vendor is actually selling you
Vendor language in this space is not always precise about which layer it covers, and a buyer has to ask directly rather than infer it from a product name.
Questions that reveal which layer a vendor's demo is actually showing you
- What is the unit of data it reads?
A questionnaire response and a contract PDF are TPRM inputs. A loan tape with thousands of rows is a loan-level input. If a demo only ever shows the former, it is not testing output.
- Can it tell you a specific loan failed a specific rule?
A TPRM platform can tell you a partner attested to a pricing control. Only a loan-level tool can name the loan, the rule and the row.
- Does it test every decision, or a sample?
Ask for the actual coverage percentage against a partner’s real weekly volume, not against a demo dataset sized to look complete.
- Who reviews a finding before it counts as one?
Both layers need a human decision behind any finding that affects a partner; ask who that person is and what they see.
- Does it replace your due-diligence process, or sit on top of it?
A loan-level tool that claims to replace due diligence is overselling scope it was never built for.
A TPRM platform's own costs and return are a separate calculation entirely, because it is solving a different part of the problem; the real cost of the quarterly review that loan-level testing replaces is broken down on its own guide.
Questions people ask
Is third-party risk management software the same as fintech partner oversight software?
No. TPRM software tracks a relationship's paperwork — questionnaires, contracts, due-diligence files. Fintech partner oversight tests the relationship's actual weekly output: the loans, the notices, the complaints and the ads, against the bank's own program rules.
Does third-party risk management software test loan-level data?
Generally not as a native capability. Loan-level testing needs a different input — a tape of individual decisions tested against pricing and underwriting rules — than a questionnaire-based platform is built around, though some platforms can accept a tape as an attached document without testing its rows.
What does fintech partner oversight software check that a TPRM platform does not?
Every decision on a partner's weekly loan tape against the program grid and rate caps, every adverse action notice against the decision that produced it, complaint trends, live marketing claims, and OFAC screening coverage — tested weekly, not attested to annually.
Do banks need both a TPRM platform and loan-level testing software?
Generally yes. Due diligence establishes whether a relationship should exist and under what terms; loan-level testing checks whether the relationship's actual weekly activity stays inside those terms. Neither answers the other's question.
How can I tell which layer a vendor's demo is actually showing me?
Ask what unit of data it reads — a questionnaire response or a loan tape row — whether it can name a specific loan that failed a specific rule, and what share of a partner's real weekly decisions it actually tests, rather than a demo dataset sized to look complete.