There is a version of third-party risk management that looks very impressive in a spreadsheet.
Every vendor has a row.
Every row has a status.
Every vendor got the questionnaire.
Every questionnaire has 300 questions.
Green means complete.
Congratulations.
You have successfully measured whether people filled out forms.
The harder question is whether you actually understand the risk.
That question matters even more after a September 11, 2026 proposal from the Office of the Comptroller of the Currency, Federal Reserve Board, Federal Deposit Insurance Corporation and National Credit Union Administration.
The agencies are proposing revised third-party risk management guidance that would replace existing guidance when finalized. The proposal emphasizes aligning third-party risk management practices with the reasonably assessed risk of each individual relationship and tailoring those practices to the financial institution's size, complexity and risk profile.
It also explicitly discusses avoiding overly process-driven strategies that treat all third-party relationships as inherently higher risk.
That sounds like common sense.
It also makes the job harder in one very important way.
You can't hide behind the questionnaire anymore.
There is an easy way to misread a move toward more tailored third-party risk management.
"Great. Less vendor management."
That's not the point.
The proposed guidance says the agencies want financial institutions to prioritize third-party risk management based on the magnitude and likelihood of potential harm from individual relationships.
In plain English: spend more attention where more can go wrong.
That's very different from simply doing less.
A company delivering office supplies doesn't create the same risk as a fintech initiating payments from customer accounts.
A marketing platform doesn't necessarily create the same exposure as a core processor.
A vendor that never sees customer data isn't the same as one storing credentials, cardholder data or personally identifiable information.
A provider that can be unavailable for a day without meaningful consequences isn't the same as one whose outage can stop customers from accessing money.
Treating all of those relationships identically doesn't make the program conservative.
It can make the program less useful.
Vendor questionnaires have a purpose.
They create consistency. They help gather information. They can identify obvious gaps. They give risk teams a repeatable starting point.
The problem starts when the questionnaire becomes the program.
We sent it.
They answered it.
Somebody reviewed it.
Box checked.
But third-party risk isn't created by the number of unanswered questions.
It's created by what the relationship actually does.
Start with the money flow.
Can the third party initiate a transaction?
Can it redirect funds?
Does it calculate balances?
Does it control settlement instructions?
Does it sit between the bank and the customer?
Can it make a mistake that creates a financial loss before anyone notices?
Then follow the data.
What customer information does it receive?
What credentials does it store?
What systems can it access?
What happens if those systems are compromised?
Then follow the operational dependency.
What stops working if the vendor disappears tomorrow morning?
How quickly can you replace it?
Is there a manual workaround?
Has anyone ever tested that workaround?
Those questions tell you much more about risk than whether question 184 in a spreadsheet says "Compliant."
Bank-fintech relationships are a perfect example of why third-party risk can't be reduced to a generic checklist.
"Fintech" describes an industry category. It doesn't describe a risk profile.
One fintech may provide a user interface while the bank controls the accounts, ledger, transaction execution and customer funds.
Another may sit deeply inside onboarding, identity verification, transaction processing, account servicing, fraud controls and customer communications.
Those aren't the same relationship.
They shouldn't be managed as if they are.
The same applies to payment facilitators, processors, gateways, program managers, embedded finance providers and other companies in the payments chain.
What matters is the function being performed, the dependencies being created and the harm that can result if the third party fails to perform as expected.
Most mature vendor programs already have some concept of criticality or risk tiers.
The interesting question is how those tiers were assigned.
If every vendor that touches customer information automatically becomes "high risk," you may still have a classification system that's too broad to be useful.
If every fintech is automatically treated as critical because somebody doesn't like the word fintech, that's not risk-based either.
A useful tiering methodology should be able to explain why.
Why does this relationship require enhanced diligence?
Why does that one require more frequent monitoring?
Why do we need stronger contractual protections here?
Why does this provider need deeper business continuity testing?
Why is senior management paying attention to this relationship and not the other 400 vendors?
The answer shouldn't be "because that's what our matrix says."
The matrix should reflect the answer.
In payments, one of the fastest ways to understand a third-party relationship is to map the actual transaction flow.
Where does the transaction start?
Who receives it?
Who makes decisions about it?
Who stores the credentials?
Who controls the merchant or customer relationship?
Who moves the money?
Who reconciles it?
Who handles disputes?
Who can stop the transaction?
Who can change where the money goes?
Suddenly "Vendor A" isn't just a row in a vendor inventory.
It's a specific dependency inside a financial process.
That's the level where risk becomes understandable.
One-size-fits-all programs are inefficient, but they have one enormous organizational advantage.
They're easy to defend internally.
Everybody gets the same thing.
Nobody has to make a difficult judgment.
Risk-based programs require judgment.
Somebody has to decide that Relationship A deserves substantially more scrutiny than Relationship B.
Somebody has to document why.
Somebody has to revisit that decision when the product changes.
Somebody has to notice when a vendor that started as a small integration becomes deeply embedded in critical operations three years later.
That's where governance matters.
Risk isn't static because vendor relationships aren't static.
Banks aren't the only organizations that should pay attention to this shift.
Fintechs should understand how they fit into a bank's risk model.
If your product moves money, handles sensitive data, performs critical operational functions or creates meaningful compliance dependencies, expect the bank to care deeply about the controls around those activities.
The best response isn't to complain that the bank is asking too many questions.
It's to make the risk easy to understand.
Know your architecture.
Know your money movement.
Know your control environment.
Know your subcontractors.
Know your incident response process.
Know your business continuity plan.
Know which responsibilities belong to you and which belong to the bank.
A fintech that can explain its risk clearly is much easier to diligence than one that sends a SOC report and hopes everyone stops asking questions.
The agencies' proposal is still proposed guidance. Comments are due 60 days after publication in the Federal Register, and the final guidance may change.
But the direction is worth paying attention to now.
Third-party risk management shouldn't be a contest to see how many vendors can be pushed through the same workflow.
It should help an institution understand where third parties can actually hurt it, its customers or the financial system, and allocate attention accordingly.
That requires better inventory.
Better classification.
Better understanding of transaction and data flows.
Better ownership.
Better ongoing monitoring.
And, yes, sometimes fewer pointless questions.
A risk-based program isn't permission to care less about vendor risk.
It's a requirement to understand it better.
Sources: