Third party risk management for lenders buying statement analysis software means checking, before any borrower statement is uploaded, that the vendor can protect the data and do the job. Banks follow the 2023 interagency guidance. Nonbank lenders and brokers follow the FTC Safeguards Rule. Both expect due diligence, a contract with safeguards and periodic review.
Which third party risk management rules reach a lender buying software?
Third party risk management rules depend on who regulates the lender. Banks supervised by the Federal Reserve, the FDIC or the OCC follow the interagency guidance on third-party relationships issued in June 2023. Nonbank lenders, mortgage brokers and finance companies under the FTC follow the service provider section of the Safeguards Rule. The duties overlap more than they differ.
The FDIC's letter on the interagency third-party guidance, FIL-29-2023 explains that the three agencies replaced their separate guidance with one document. It takes a risk-based approach, so practices should match the bank's size and complexity and the risk of the relationship. It also says that using a third party does not diminish or remove the bank's responsibility to operate safely and follow the law.
For lenders outside banking, the Cornell LII text of the FTC Safeguards Rule, 16 CFR 314.4 sets three duties in paragraph (f). Take reasonable steps to select and keep service providers that can maintain appropriate safeguards. Require them by contract to implement and maintain those safeguards. Periodically assess them based on the risk they present.
A statement analysis vendor holds some of the most sensitive data a lender collects: full account numbers on some statements, every payee the borrower paid, payroll deposits, medical bills and child support. That puts it near the top of most lenders' vendor risk lists, whichever rule applies.
Third party risk life cycle stages for a statement analysis vendor
The third party risk life cycle has five stages: planning, due diligence, contract negotiation, ongoing monitoring and termination. The interagency guidance names all five. A statement analysis vendor passes through each one, and the work at each stage is different.
Planning
Write down what the software will do and what data it will receive. A tool that reads statements for income analysis receives full statements, not summaries. Decide who on the team will use it and what happens if it is unavailable for a day.
Due diligence
Send the security questionnaire, request the SOC report or equivalent evidence, and test the product on sample files with known answers. Testing is part of diligence, because a vendor that protects data well but miscounts deposits is still a risk.
Contract negotiation
Put the safeguards in writing. The Safeguards Rule requires it for nonbank lenders, and the interagency guidance treats it as a core stage for banks.
Ongoing monitoring
Review the vendor on a schedule set by its risk: a new SOC report each year, a check of any reported incidents, and a look at whether the product still gives correct figures after updates.
Termination
Plan the exit before signing. The lender needs its reports back in a usable format and written confirmation that borrower statements were deleted.
Security questionnaire for a bank statement software vendor
A security questionnaire for a bank statement software vendor should ask how the data is protected, who can see it, where it is stored, how long it is kept and what happens after an incident. The checklist below gives each question with the answer a lender should look for. The answers are examples, not a standard.
| Question | Answer to look for |
|---|---|
| Is borrower data encrypted in transit and at rest? | Yes, for both, with the method named |
| Who at the vendor can access uploaded statements? | A named, limited group, with access logged |
| Can the lender limit access to its own team members? | Yes, with per-user accounts |
| Is multi-factor authentication available for lender users? | Yes |
| How long are statements kept, and who decides? | The lender sets the period, and files are deleted on schedule |
| Is borrower data used to train or improve products? | No, or only with the lender's written agreement |
| Where is data stored and processed? | Named regions, inside the country unless agreed |
| Which subcontractors touch the data? | A current list, with notice before changes |
| How fast will the vendor report a security incident? | A fixed number of hours or days, in the contract |
| What independent assurance is available? | A current SOC 2 report or a comparable assessment |
| Can the lender export its reports and delete everything on exit? | Yes, with written confirmation of deletion |
Ask for evidence, not just yes or no. A screenshot of the retention setting, a copy of the subprocessor list or a page from the SOC report answers more than a checkbox.
TrueBankFlow's published answers cover several of these rows: statements are encrypted in transit and at rest, access is limited to the lender's team, and the lender chooses how long files are kept after a report is exported. Read TrueBankFlow's data handling answer.
What does a vendor SOC 2 report prove to a lender?
A vendor SOC 2 report is a CPA's examination of the controls at a service organization over its systems. It tells a lender whether an independent auditor found the vendor's controls designed, and in a Type 2 report operating, as described. It does not prove the software calculates correctly, and it covers only the systems and period it names.
The AICPA's overview of SOC 2 reporting describes reports addressing security, availability, processing integrity, confidentiality or privacy. A vendor chooses which of these categories to include. A report that covers only security says nothing about whether the vendor met privacy commitments.
Read four parts of the report rather than the cover letter alone:
- The scope. Confirm the system described is the product the lender will use, not a different product line.
- The period. A Type 2 report covers a stretch of time. A report whose period ended a year ago leaves a gap. Ask for a bridge letter covering the time since.
- The exceptions. Auditors list control failures they found. A few minor exceptions are common. A pattern in access control is not.
- The complementary user controls. These are controls the lender must run itself, such as removing access for staff who leave. If the lender does not run them, the vendor's controls may not protect the data.
A young vendor may not have a SOC 2 report yet. In that case, ask for a written security description, the results of any outside testing and a date for the first audit, and weigh the risk accordingly.
Data location and subcontractor questions for borrower statement data
Data location and subcontractor questions find out where borrower statements physically sit and which other companies process them. A software vendor almost always relies on cloud hosting, and often on separate services for email, document reading or logging. Each one is a fourth party to the lender, and each one sees some of the data.
Ask the vendor for a list of subcontractors that store or process borrower data, with what each one does and where. Ask how the vendor reviews those subcontractors. Ask for notice before a new one is added, with a chance to object.
Location matters for two reasons. A bank's own policy, or a contract with an investor, may limit where consumer financial data can be stored. And a breach at a subcontractor can set off the lender's own notice duties just as a breach at the vendor would.
The same questions apply to other third parties in a lending business, not only software. A merchant cash advance funder relies on independent sales organizations to bring deals and submit statements. The guide to which states require an MCA broker license covers one check funders run on those ISOs. Funders that collect through a card processor take on another third party, and the guide to MCA split funding through the processor shows where that relationship sits in the deal.
Vendor contract terms that protect borrower statement data
Vendor contract terms turn the questionnaire answers into obligations. A good contract for statement analysis software states what data the vendor may use, for what purpose, how it is protected, how fast incidents are reported, how long data is kept and how it is returned or destroyed at the end. Without those terms, the answers are promises.
The clauses to look for:
- Permitted use. The vendor uses borrower data only to provide the service to the lender.
- Safeguards. The vendor maintains the security controls described in its questionnaire answers, and tells the lender before weakening them.
- Incident notice. The vendor reports a security incident affecting lender data within a stated time, with the facts the lender needs for its own notices.
- Subcontractors. The vendor passes the same obligations to its subcontractors and stays responsible for them.
- Audit and assessment. The lender can request the latest SOC report and reasonable evidence of controls.
- Retention and deletion. The vendor deletes borrower data on the lender's schedule and at termination, with written confirmation.
- Exit. The lender can export its reports in a usable format before the account closes.
The contract should also say the vendor does not make the credit decision. Statement analysis software organizes data for an underwriter. The lender owns the decision and the rules behind it. That matters for fair lending: a vendor's default category rules must not quietly drop income a lender cannot discount. The post on Regulation B rules for public assistance income explains why benefit deposits need the same treatment as other income.
When a full vendor review is more than the software relationship needs
A full vendor review is more than a relationship needs when the vendor never touches borrower data and nothing important depends on it. The interagency guidance says not all third-party relationships carry the same risk, and the Safeguards Rule ties assessment to the risk a provider presents. A lender should tier its vendors and match the review to the tier.
A scheduling tool that holds only staff calendars sits in a low tier. A short questionnaire and a contract review may be enough. A statement analysis vendor, an upload portal or a loan origination system sits in the top tier, because each holds full borrower financial records.
The mistake is the opposite one: treating a high-risk vendor as low risk because it is small or because the first files are a pilot. A pilot with real borrower statements carries the same data risk as full use. Run the full review before the first real file, even when the pilot is free.
Record the tier, the reason for it and the date of the next review in one vendor inventory. When an examiner or auditor asks how vendors are overseen, that inventory is the answer.