Reporting & Compliance guide: Underwriting Audits: How to Make Every Loan File Reviewable, from Policy Versions to Investor Requests

An underwriting audit is a review of funded or declined files that tests whether each decision followed the policy in force at the time, rested on genuine evidence and was approved by someone with the authority to approve it. For an MCA funder or SMB lender, being audit-ready means any file can be produced with its documents, policy version, findings, overrides and decision without anyone rebuilding it from email.

This guide is the practical side of that idea. It covers who actually audits an alternative lender's files and what each of them asks for, a file-review checklist you can run yourself, how the auditing profession's assertions (existence, rights and obligations, valuation, completeness) map onto underwriting evidence, how to version credit policy so you can always say which version decided which file, how to keep and retrieve records, how to sample files, the findings that come up most often, and how to build transparency into the workflow instead of reconstructing it the week before a review. Why an evidence-linked trail matters in principle is covered in our piece on underwriting audit trails; this one is about getting through the audit itself.

01Who audits an MCA or SMB lender's underwriting files?

Most alternative lenders face several reviewers, not one: their own internal audit or QC function, the investors and capital partners who fund the book, warehouse or credit-facility lenders, syndication participants, bank partners, external financial-statement auditors, buyers in a transaction, and regulators where a given product and state bring them in. Each reads the same files for a different reason.

• Internal audit and quality control. Tests whether underwriting follows the written policy, whether exceptions were approved at the right level, and whether practice differs between underwriters, ISOs or product lines. Usually the most frequent reviewer and the most useful one.
• Investors and capital partners. Want to know that the book they funded was underwritten the way the deck and the operating agreement said it would be. Expect requests for policy documents, a sample of files, override statistics and performance by cohort.
• Warehouse and credit-facility lenders. Test eligibility: does each receivable pledged to the facility meet the criteria in the credit agreement? Their field audits often trace a sample from the borrowing-base report back to the signed contract and funding record.
• Syndication participants. A participant who bought a share of a deal relies on the lead's underwriting. They may ask for the file behind a specific position, especially after a default.
• Bank partners. Where a bank is involved in origination or funding, the bank's own third-party risk program shapes what it can ask of you, including audit rights written into the contract.
• External auditors. A financial-statement audit of the lender tests the receivables on the balance sheet, which pulls underwriting files in as evidence for existence and valuation.
• Acquirers and lenders in a transaction. Due diligence on a portfolio or a company reviews underwriting quality as a proxy for future losses.
• Regulators and state examiners, where applicable. Commercial financing rules differ by state and by product, and whether a given MCA program is subject to a particular rule is a legal question for counsel. Where a regulator does have jurisdiction, the file has to stand on its own.

On the bank side, the federal banking agencies' interagency guidance on third-party relationships (final as of June 6, 2023) says a contract generally includes provisions for periodic, independent audits of the third party, may describe the audit reports the bank is entitled to receive, and may reserve the bank's right to conduct its own audits. If you originate or fund alongside a bank, assume the bank can and will ask to see how your files are underwritten, and that its examiners may ask the bank the same question.

02What do auditors and investors request in an underwriting audit?

Almost every underwriting audit request reduces to four questions about a specific file: what did you know when you decided, which rules were you applying, who decided, and what was still open when they did. Requests differ in sample size and format, but the evidence they need is the same.

1. The credit policy and underwriting guidelines, with every version in force during the review period and a log of what changed, when and who approved it.
2. A portfolio tape or funded-deal list for the period, reconciled to the general ledger or servicing system.
3. The full file for each sampled deal: application, borrower documents, analysis, verification, fraud review, policy evaluation, the underwriting report or credit memo, approval record and funding record.
4. An exception and override log, with approver, reason and outcome.
5. Delegated authority limits: who can approve what size of deal, and under what conditions.
6. Quality-control results from your own reviews, with findings and remediation status.
7. Your record-retention policy, and evidence that it is followed.
8. A list of third-party data and software vendors used in underwriting, and how their output is checked.

The phrase people search for is investor audit record retrieval, and retrieval is where most lenders struggle. The documents usually exist somewhere, in a shared drive, a CRM attachment or an inbox, but nothing ties them together or records which policy version the memo was written against. Answering the request becomes a reconstruction project, and reconstruction is where errors creep in.

The front page of that trail is usually the underwriting report or credit memo. In an audit it does a different job than it did on the day of the decision: it becomes the index to everything else. A report that states a figure without a link to its source forces the auditor to re-derive the figure, which is slow and invites disagreement. What a good report contains is covered in evidence-backed underwriting reports; for audit purposes, the test is simply whether every number and every conclusion in it can be traced in one step.

03Underwriting audit checklist: how to review a loan file

A file review checks six things in order: the applicant and signer are real and authorized, the documents are complete and genuine, the analysis ties to the documents, verification and fraud review happened before funding, the deal was evaluated against the right policy version, and the decision was made and approved by someone with authority. Run the same checklist on every sampled file so results are comparable.

Identity, entity and authority

• Legal name, entity type, state of formation and status match across application, contract, bank statements and the registry result. Differences are explained in a note.
• The registry or verification result is in the file with its source and the date it was run, before the funding date. See the KYB guide for lenders for what that check covers.
• The signer's authority to bind the business is documented (owner, officer or written authorization).
• Owner identity checks your policy requires are present and dated.

Documents and integrity

• Every document the policy requires is present: application, the required months of bank statements, ID, voided check or account verification, and any tax or processor statements your product needs.
• Statement periods are recent relative to the decision date, as your policy defines recent.
• The original uploaded files are retained, not only extracted data or re-saved copies, with a record of when and how each arrived.
• Any document-integrity review is recorded, including flags raised and how each was resolved. How to detect edited bank statements lists what that review should look at.

Analysis that ties to source

• Revenue, deposits, average daily balance, NSF and negative-day counts in the memo can be recomputed from the statements, and the reviewer gets the same answer.
• Excluded deposits (transfers between own accounts, loan proceeds, refunds) are identified and the exclusions are explained.
• Existing advances and debt service visible in the statements are listed, so a stacking position is not missed. See detecting stacking.
• Every figure in the memo links to the page and line it came from, which is what source-linked extraction means in practice.

Policy, decision and funding

• The file records which policy version evaluated it, and that version was in force on the evaluation date.
• Each policy criterion shows a result tied to the underlying data, not a single pass or fail label.
• Every exception or override has an approver, a reason in the approver's own words and a date. Why overrides need an audit trail covers what that record should contain.
• The approver's authority covered the deal size and any exceptions.
• Funding happened after approval, for the approved amount and terms, to the verified account.
• Open conditions at approval (for example, a missing month to be supplied before funding) were cleared and the clearing is recorded.

04How do audit assertions map to underwriting evidence?

Auditors organize their testing around assertions, the implicit claims behind every balance on a financial statement. For a lender, the receivables or advances on the balance sheet carry those claims, and the underwriting file is much of the evidence for them: that the advance exists, that the lender holds the rights to it, that it is carried at an appropriate amount, and that the population is complete.

The PCAOB's auditing standard on audit evidence, AS 1105, classifies financial statement assertions into five categories: existence or occurrence, completeness, valuation or allocation, rights and obligations, and presentation and disclosure. Collectability is not a separate assertion in that list; whether a receivable will be collected is tested as part of valuation, because a receivable carried at more than it will realize is overstated. Private-company audits follow AICPA standards whose wording differs slightly, but the ideas map the same way.

Existence: the advance and the merchant are real

An auditor testing existence picks deals from the books and looks for evidence that each one happened: a signed agreement, a funding wire to a verified account, and evidence the counterparty is a real operating business. The underwriting file supplies the last part. A verification result run before funding, with its source and date, is far stronger evidence than a note saying the business was verified.

Rights and obligations: the lender holds the receivable

Rights and obligations asks whether the receivable belongs to the lender at the balance-sheet date. For an MCA or business loan, that means an executed contract signed by someone with authority, any UCC filing your program uses, and records of participations or sales to syndication partners or a facility, so the lender is not claiming the full value of a deal it has partly sold. Signer authority is the piece most often thin in the file.

Valuation and collectability: carried at the right amount

Valuation is where underwriting evidence matters most. Reserve and impairment estimates rely on the assumption that deals were underwritten consistently, so an auditor may test whether the underwriting that supported each deal was sound: the cash-flow analysis, the policy evaluation, the exceptions taken, and collections since funding. A cohort with a high override rate and weak early performance invites harder questions about reserves.

Completeness: nothing missing from either side

Completeness runs in both directions for a lender. Every funded deal on the tape should have a complete file, and every file marked as funded should appear on the tape and in the ledger. Orphans in either direction are a classic finding: a deal funded through a side process that never reached the underwriting system, or a file approved and marked funded that was in fact cancelled.

A question that appears in search almost word for word is what banking software can review loans by audit assertions. No single software category does this on its own. The servicing or loan-management system holds the population (the tape) and the payment history; the underwriting record holds the evidence for existence, rights and valuation; the general ledger holds the balances. Assertion-based review works when the three share a stable deal identifier, so an auditor can move from a ledger balance to a tape line to a file without matching names by hand. When evaluating tools, ask to see that path for one deal, end to end.

AS 1105 also explains why the form of evidence matters. In general, it says, evidence from a knowledgeable source independent of the company is more reliable than evidence from internal sources only, and evidence from original documents is more reliable than photocopies or documents converted to electronic form, whose reliability depends on the controls over conversion and maintenance. For a lender, that argues for keeping the originally uploaded files unchanged alongside any extracted data, recording where each third-party result came from, and controlling who can alter what.

05How do teams control underwriting policy and model versions?

Teams control underwriting versions by treating credit policy like released software: every change gets a new version number, an effective date, a written reason and a named approver, old versions are never edited in place, and every file records the version that evaluated it. That last step is what lets you answer which version decided which file.

A chief credit officer gets this question in every serious review. If an auditor picks a March file and today's policy shows a higher minimum balance than the file meets, the only defensible answer is the policy in force in March, and a record that it was.

• Version identifiers. A simple scheme (v3.3, v3.4) is enough. Increment on every change to a threshold, a required document, a scoring weight, a decline rule or an authority limit.
• Effective dates, not edit dates. Each version has an effective-from date and, once replaced, an effective-to date. The effective date is when it applies to files, which may differ from when it was approved.
• A change log with reasons. What changed, why (loss experience, a capital partner's eligibility criteria, a new product), who approved it and when.
• No in-place edits. A correction is a new version, even a typo fix that changes a number. Superseded versions stay readable.
• Files pinned to versions. The evaluation record on each file stores the version identifier it was evaluated against, not a link to whatever the policy says today.
• Re-evaluation creates a new record. If a file is re-run under a new version (a renewal, a deal that sat in review across a change), the original evaluation is kept and the new one sits beside it.
• Models and tools are versioned too. Scorecards, AI extraction or classification models, verification vendors and their configurations change over time. Record which version of each produced the findings in a file.

A version record does not need to be elaborate. What matters is that it is written once, never overwritten, and referenced by identifier from every evaluation. The example below shows the minimum useful shape for a policy version and for the evaluation record a file keeps.

{
  "policyVersion": {
    "id": "v3.4",
    "effectiveFrom": "2026-06-15",
    "effectiveTo": null,
    "supersedes": "v3.3",
    "approvedBy": "Credit committee",
    "approvedOn": "2026-06-09",
    "reason": "Add NSF limit for renewals after cohort review",
    "changes": [
      { "rule": "renewal.nsfCount.max", "from": null, "to": 3 }
    ]
  },
  "evaluation": {
    "fileId": "CS-0412",
    "evaluatedAt": "2026-06-20T14:05:00Z",
    "policyVersion": "v3.4",
    "toolVersions": { "extraction": "2026.06.1", "verificationSource": "state registry" },
    "supersedesEvaluation": "CS-0412-eval-1",
    "results": [
      { "rule": "adb.min", "value": 6840, "threshold": 6000, "outcome": "met", "evidence": "statement-2026-05.pdf#p2" }
    ],
    "openItems": ["Explain March transfer from related account"],
    "decision": { "by": "Named underwriter", "authorityLimit": "within limit", "recordedAt": "2026-06-21T09:12:00Z" }
  }
}

Which version decided which file?

The edge cases are where audits find problems. A deal submitted on June 12 and decided on June 16 straddles the change from v3.3 to v3.4. Decide in writing which date governs (submission, evaluation or decision), apply that rule consistently, and record it on the file. Renewals need the same treatment: a renewal is a new decision and should be evaluated under the current version, with the original deal's evaluation left untouched. If you allow a deal in flight to finish under the old version, say so in the change log and record which files used that allowance.

For lenders with bank partners, the bank's own model-governance expectations are a useful reference. The Federal Reserve's SR 26-2, revised guidance on model risk management, issued April 17, 2026 by the Federal Reserve, OCC and FDIC, supersedes the long-standing SR 11-7 and emphasizes a risk-based approach tailored to each institution. The letter says it is most relevant to banking organizations with over $30 billion in total assets, so it does not bind a non-bank funder directly, but a bank partner applying it to its own models may ask how scorecards and AI tools in your workflow are versioned and monitored.

06Record retention and retrieval: how do you find any file's evidence in minutes?

Fast retrieval comes from three design choices made before any audit: a stable file identifier used in every system, original documents and evaluation records stored together and never overwritten, and retention set per data type with legal holds that suspend deletion. Get those right and producing a file is a lookup, not a search.

How long to keep records depends on your product, your contracts and the law that applies to you, and it varies. Where the Equal Credit Opportunity Act applies, Regulation B, section 1002.12 sets a 12-month retention period for business credit, measured from notice of action taken; for applicants with gross revenues over $1 million in the preceding fiscal year and certain other business credit, the minimum is 60 days, extended to 12 months if the applicant asks in writing for reasons or for records to be kept. Records must be kept beyond those periods once the creditor has actual notice of an investigation or enforcement proceeding. Whether a merchant cash advance is credit for these purposes depends on how it is structured and on the jurisdiction, so that is a question for counsel rather than a default assumption.

In practice, regulatory minimums are rarely the binding constraint. Capital-partner agreements, facility agreements, state commercial-financing rules, tax rules and litigation risk usually set longer periods, and a file needs to outlive the deal it supports, including the collections period. Write the retention schedule by data type rather than one blanket period, which is the approach our security page describes for underwriting data:

• Source documents as received, with the date and channel of arrival and a content hash so you can show they have not changed.
• Underwriting records: extracted data, findings, policy evaluations, the report and the decision.
• Review activity: who viewed, edited, overrode or approved what, and when.
• Operational logs: system events that support the activity record, often on a shorter clock.
• Legal holds that suspend deletion for named files or date ranges, and a deletion log showing what was destroyed under the schedule and when.

Then test retrieval the way an auditor will. Once a quarter, pick ten files at random, including at least one declined deal and one more than a year old, and time how long it takes to produce each complete file with its policy version and decision record. Anything that requires asking a person where something is counts as a failure. The point of the drill is not the number; it is finding the gaps before a capital partner does.

07How should you sample files for an underwriting audit?

Use a mix: a random or stratified sample to say something about the whole population, plus a targeted selection of the riskiest files (overrides, exceptions, early defaults, large deals). Keep the two apart in reporting, because results from a targeted selection describe those files only and cannot be projected to the book.

AS 1105 describes three ways of selecting items for testing: selecting all items, selecting specific items, and audit sampling. It notes that testing all items can make sense when a population is a small number of large items, when the risk is significant, or when the procedure can be automated across the whole population. It also states that results from specific items selected for a characteristic, such as items that are unusual or risk-prone, cannot be projected to the entire population. The same logic works for an internal file review.

1. Test everything that can be automated. Some checks run on every file cheaply: is a policy version recorded, is the decision timestamp after the verification timestamp, did funding follow approval, is the approver within their limit. Run these across 100 percent of the period.
2. Draw a stratified sample for judgment checks. Split the population by the factors that change risk: deal size band, ISO or channel, underwriter, product, policy version. Draw randomly within each stratum so a small but important segment is not missed.
3. Add a targeted selection. Every override above a threshold, every deal with an unresolved fraud flag at approval, first-payment and early defaults, renewals and the largest deals. Report these separately.
4. Include declines. A sample of declined files tests whether the policy is applied consistently in both directions and whether decline reasons are recorded.
5. Size to the purpose. A monthly QC sample can be small and steady; a pre-diligence review before a capital raise might be larger and weighted toward recent cohorts. Agree the size with whoever relies on the result.

An illustrative quarter for a funder writing a few hundred deals: automated checks on every file, 25 funded files across four size bands, 10 declines, and every override of the minimum balance or position-count rule. Record the sampling method with the results.

08What are the most common underwriting audit findings, and how do you fix them?

Most underwriting audit findings are not bad credit decisions; they are decisions that cannot be proved. Missing documents, numbers that do not tie to source, unknown policy versions and undocumented overrides account for most of them, and each has a structural fix rather than a reminder email.

• Policy version unknown. The file cannot say which rules applied. Fix: version the policy as described above and stamp every evaluation with the identifier automatically.
• Memo figures do not tie to statements. The average daily balance in the memo cannot be recomputed. Fix: generate figures from linked extraction and keep the link, so a reviewer clicks from the number to the line.
• Override without a reason or approver. Fix: make the override a recorded action with required fields, not a free-text comment. Report override rates by underwriter and rule monthly.
• Approval above authority. A deal or exception exceeded the approver's limit. Fix: encode authority limits so the system routes the decision to the right person and records who it was.
• Verification run after funding, or not dated. Fix: record the run time of every verification and block or flag funding while required checks are outstanding.
• Fraud or integrity flag cleared without explanation. Fix: require a resolution note on every flag, written by the person who cleared it. Flags are for a person to weigh; the record shows that someone did.
• Stale documents. Statements older than the policy allows at the decision date. Fix: compute statement recency against the decision date and surface it as a policy result.
• Tape and files do not reconcile. Funded deals without files, or files marked funded that never funded. Fix: one deal identifier across underwriting, servicing and the ledger, and a monthly reconciliation.
• Inconsistent treatment. Similar files decided differently by different underwriters without an explanation. Fix: compare outcomes by underwriter within the same stratum and review differences in calibration sessions.
• Evidence lost to retention gaps. Documents lived in a mailbox that was purged. Fix: move documents into the file at intake and set retention on the file, not on the inbox.

Write each finding up as condition, criterion, cause, effect and remediation with an owner and a date, then re-test the same control next cycle. A repeat finding is more serious than a new one.

09How should a lender prepare for investor and capital-partner due diligence on underwriting?

Lender due diligence on underwriting goes faster when you prepare a standing data room before anyone asks: current and prior policy versions with the change log, a reconciled tape, a ready sample of complete files, the override log, your own QC results and the retention policy. Diligence then tests your evidence instead of waiting for you to assemble it.

Capital partners and facility lenders read files to judge whether past performance will repeat. An investment audit trail in this sense is the ability to show, for any deal in the book, the evidence and rules behind the decision, plus how often the rules were bent and with what result.

10How do you build underwriting transparency into the workflow instead of reconstructing it later?

Underwriting transparency comes from capturing evidence, versions and decisions at the moment work happens, as a side effect of doing the work, rather than writing them up afterwards. If the system that produces a finding also stores its source and the policy version, nobody has to remember to document it.

Reconstruction is expensive and unreliable. Six months later the underwriter may have left and the policy has changed twice, and a file assembled after the fact tends to agree with the present because it is written by people who know how the deal performed. Only timestamps and records that cannot be silently edited show an auditor what was contemporaneous.

• Capture at the source. Extraction keeps a link to the page and line. Verification stores the source and run time. Policy evaluation stores the version.
• Append, do not overwrite. Corrections and re-evaluations are new entries beside the original, each with an author and time.
• Make the human record first-class. Notes, overrides and approvals are structured actions inside the review, as covered in human-in-the-loop underwriting, not comments in a separate tool.
• Seal the decision. When the decision is recorded, freeze what was known, what was open and which version applied, so later edits cannot change the historical picture.
• Review yourself monthly. Run the automated checks and a small sample every month. Small, regular reviews catch drift long before an external audit does.
• Watch the aggregates. Override rates by rule, by version and by underwriter; flag-clearance times; share of files with open items at decision. These numbers tell you where policy and practice are separating.

Transparency also improves the underwriting. A policy rule overridden on a large share of files is either wrong or being ignored, and the version history shows whether the problem began with a particular change. Explainability for each finding, discussed in explainable AI in underwriting, and versioned rules from a loan policy engine are the same idea seen from the reviewer's and the policy owner's side.

From here, this article is about Cevrynt

11How Cevrynt supports audit-ready underwriting files

Cevrynt is AI-assisted underwriting infrastructure for MCA funders and alternative lenders, built so the audit record is a by-product of the review. Findings from document structuring, bank statement analysis, business verification and fraud signals keep links to their sources. The Policy Engine evaluates each file against the lender's own rules and keeps the policy version in force at the time attached to the file, and overrides are recorded under the reviewer's name with their reason, beside the original finding.

The Underwriting Report brings those findings, open items and reviewer notes together, and records that a decision was entered, by whom, when and against which policy version. The decision itself always belongs to the lender: Cevrynt is not a lender and does not fund deals, offers come from the lender's own terms and go out only when the lender decides, and its fraud and policy outputs are flags for a person rather than automatic declines. Retention is defined by data type and agreed per workflow, as described on our security page.

Cevrynt supports a lender's audit program; it does not replace internal audit, legal advice or the lender's own controls. If you want to see how a file's evidence, version and decision record would look for your workflow, book a walkthrough or discuss a focused pilot with our team.