SBA 7(a) Lending and Loan Packaging Software: Why a Missing Signature Becomes an Unsecured Loss Five Years Later

You are not selling a loan, you are manufacturing a guarantee

A 7(a) loan funded in 2021 goes into liquidation. The credit was sound, the collateral was real, the borrower simply failed. You liquidate, you file for purchase, and SBA comes back with a repair because the site visit was documented late, because a change in ownership during servicing was approved unilaterally when it required SBA consent, and because the file cannot demonstrate that the affiliation analysis considered a second entity the principal owned at application. The loss on that loan just moved from mostly guaranteed to substantially yours. Nobody made a credit error. Everybody made a file error.

That is the shape of risk in government guaranteed lending and it is unlike ordinary commercial credit. In conventional lending, documentation quality affects your recovery. In SBA lending, documentation quality determines whether the guarantee, which is the asset you underwrote against, still exists at the moment you need it. A lender with excellent credit judgment and a mediocre file discipline is running an unsecured book without knowing it.

The tooling most lenders use does not reflect this. Origination happens in a loan origination system, closing documents come from a document preparation vendor, the file lives in a shared drive folder structure organised by whoever set it up, servicing happens in the core banking system, and liquidation happens in a spreadsheet plus a folder of PDFs. The chain from the eligibility determination made at application to the evidence needed at purchase five years later crosses four systems and at least two staff turnovers.

Eligibility and affiliation are judgments, and a judgment without evidence is a defect

Eligibility screening under SOP 50 10 is not a checkbox exercise. Size determination requires affiliation analysis, which means identifying every entity a principal controls, applying the affiliation rules, and reaching a conclusion. Ineligible business types, ineligible uses of proceeds, credit elsewhere, citizenship and residency status, prior loss to the government: each is a determination someone made, and each will be tested if the loan ever reaches purchase review.

The recurring failure is not that lenders reach wrong conclusions. It is that they reach right conclusions and record only the conclusion. The file says the applicant is eligible. It does not say which entities were considered, what the analyst looked at, what the principal disclosed, and what the analyst concluded about each. Five years later that gap is indistinguishable from not having done the work.

The franchise question illustrates how unstable this ground is. SBA has moved between maintaining a central franchise directory and placing the determination squarely on the lender, and the requirements around franchise agreement review have shifted more than once in recent years. Whatever the rule is on the day you approve a loan, your file must show you applied that rule as it stood on that day. A system that only knows the current rule cannot defend a loan approved under the previous one.

What a custom build does: eligibility becomes a structured determination record, not a flag. Each element carries the analyst, the date, the documents examined, the reasoning, and the SOP version in force. Affiliation is modelled as an entity graph you can extend, so an added entity triggers a re-run of the size determination rather than a memory of having considered it. The output is a defensible narrative generated from the record, which is exactly what a purchase reviewer wants to read.

The SOP changes and your checklist is a Word document nobody versioned

SBA revises its operating procedures on its own schedule, and the revisions are substantive: what documents are required, what constitutes an eligible use of proceeds, what a lender may do unilaterally in servicing, what the collateral requirements are at various loan sizes. Most lenders manage this with a checklist document that a compliance officer updates, emails around, and hopes everyone is using the current version of. There is usually no way to know which version a given loan was packaged under.

Abrigo has genuine depth in this space and is the closest packaged fit for a bank SBA department. Baker Hill NextGen is strong at credit analysis and portfolio management. nCino is an excellent commercial origination platform with strong pipeline and workflow. What all of them leave with the lender is the interpretation: SOP rules are lender-applied, they change, and any product's implementation of them is a snapshot that trails the actual SOP by however long the vendor's release cycle is. Your compliance officer will still be maintaining a document.

What a custom build does: make the requirement set effective-dated data. A loan is stamped with the SOP version in force at application, and the checklist, document requirements and validation rules it must satisfy are the ones from that version, permanently. When a new SOP lands, your compliance officer configures the new version with its effective date; loans in flight either continue under the old version or are explicitly migrated with a recorded decision. Nobody guesses, and every file can state which rule set it was built against. This single design decision is what converts SOP churn from an annual fire drill into a data entry task.

Document presence is easy. Document currency is what kills you

Every lender's checklist confirms a document exists. Very few systems know whether it is still good. Financial statements have an age limit at closing. A tax transcript ordered in March does not support a closing in October. Insurance lapses. A UCC filing has a continuation date. An environmental report has a shelf life. A borrower's 1919 signed before a change in ownership structure no longer describes the borrower.

The classic sequence: a loan approved in spring, delayed by a construction issue, closes in autumn on financials that aged out, and nobody notices because the checklist item was ticked in spring. It surfaces at purchase.

What a custom build does: every document has a type, an as-of date, a validity rule and a state that is computed rather than stored. The closing package cannot be marked complete while any required document is stale under its own rule. Expiry is forecast, so the team is told in week two that the transcript will age out before the projected closing date rather than discovering it on the day. Signature completeness is tracked at the signature block level, because the most common defect we see is not a missing document but a document present and unsigned by one of three guarantors.

E-Tran, servicing actions and the long silent middle

Submission through E-Tran has its own data discipline and its own rejection behaviour, and the fields SBA holds must continue to match your records for the life of the loan. That is easy at origination and gets progressively harder. The loan boards to your core, the SBA department stops looking at it daily, and then things happen: a change in ownership, an additional loan to the same borrower, a collateral release, a deferment, a workout. Each is a servicing action, each has a rule about whether the lender may act unilaterally or must obtain SBA consent under the servicing SOP, and each is a point where a guarantee can be impaired quietly.

Origination platforms are built for the origination. Once the loan boards, the SBA-specific obligations become the department's tribal knowledge and a shared mailbox. A servicing action taken correctly but undocumented is functionally identical at purchase to one taken incorrectly.

What a custom build does: carry the loan as a guarantee file for its whole life, not just its origination. Servicing actions are initiated in the system, the unilateral versus consent determination is made against the SOP version in force at the time of the action, evidence of the decision and any SBA correspondence is attached, and the record is permanent. Site visit requirements after default are tracked with their deadlines. The transcript of account is maintained continuously rather than reconstructed. Every one of those is a line a purchase reviewer will look for.

The purchase package is assembled by someone who was not there

Five years after origination, a loan defaults. The person who underwrote it has left. The purchase package requires the full narrative: eligibility, use of proceeds, closing, servicing history, default, liquidation actions and recovery, with supporting documents assembled in the order SBA expects. A workout officer now spends two to four weeks reconstructing a story from four systems and a folder, and every gap in that reconstruction is a candidate for repair.

What a custom build does: assemble the package continuously rather than at the end. Because eligibility determinations, document evidence, servicing actions and liquidation steps were all captured as structured records at the time they happened, the purchase package is generated with an index, cross-references and a completeness report showing what is missing before you submit rather than after SBA tells you. Lenders who have built this describe the change in the same way every time: purchase preparation stops being an archaeology project and becomes a review.

There is a second benefit that is harder to quantify and matters more. When the system tells you at year three that a loan's file has a gap, you can still fix it. Gaps found at liquidation are permanent.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this category prices as follows. A first release covering structured eligibility and affiliation determination, SOP-versioned checklists and document requirements, document currency and signature tracking, and E-Tran submission with error handling runs $80,000 to $170,000 over 12 to 18 weeks. A full platform adding closing coordination, servicing action workflow with unilateral versus consent logic, liquidation and site visit tracking, transcript maintenance and generated purchase packages runs $200,000 to $500,000 phased over 7 to 14 months.

Cost drivers specific to SBA lending: whether you run 7(a) and 504 together, since 504 brings the CDC relationship, the debenture funding cycle and a different document set. Whether you are a bank with a core to integrate or a non-bank lender with a servicing platform. Secondary market sales, which add settlement and investor reporting. And your existing document estate, because if the plan includes migrating an existing portfolio's files into the structure, that is a real workstream and the value of doing it depends on how much of the portfolio is seasoned enough to matter.

What holds cost down: building the guarantee file layer first and integrating origination second. Many lenders keep nCino or Abrigo for pipeline and credit and build only the SBA-specific evidence spine around it, which is both cheaper and less disruptive than a replacement.

Build versus buy

Buy if you close under roughly 40 SBA loans a year. Abrigo plus a maintained checklist and a disciplined SBA manager is proportionate, and the fixed cost of a build will not amortise across that volume.

Build when volume, staff turnover or repair experience makes file risk systemic rather than individual. Concretely: you originate above roughly 150 loans a year, you have had a repair or denial that traced to documentation rather than credit, your SBA department has lost a key person and discovered how much lived in their head, or you are a non-bank lender whose entire business model depends on the guarantee and whose funding partners diligence your file quality. That last case is the strongest, because for a non-bank SBA lender the file is not a compliance artefact, it is the collateral.

Keep buying what is genuinely commodity. Document preparation vendors, closing document generation and credit scoring models are all reasonable to keep. What you should own is the determination record and the evidence chain, because those are the things SBA will examine and the things no vendor can maintain to your interpretation.

How to choose a developer for SBA lending software

Ask how a loan approved under a prior SOP version is validated. The answer must involve effective-dated requirement sets and a version stamp on the loan. A system that only knows today's rules will fail every historical file it touches.

Ask how they model affiliation. An entity graph that can be extended, with size determination recomputed when it changes, is the correct shape. A text field where an analyst types a conclusion is what you already have.

Ask how they distinguish a required document being present from being current. If validity rules, as-of dates and computed staleness are not in the answer, the system will confirm you have a stale tax transcript and call the file complete.

Ask what they have integrated with E-Tran and with core banking systems, specifically which ones and how they handled rejections and subsequent field changes. Then settle ownership before kickoff: you should own the repository, the cloud environment and every determination record in it. At Digital Heroes the client owns all of it from the first commit. For a portfolio where the file is the collateral, having your evidence chain inside somebody else's platform is a risk you would never accept anywhere else in the bank.