Alternatives
Options for covenant monitoring when you already run nCino.
Last reviewed · nCino statements taken from its own published materials.
The gap people are usually trying to close
The specific problem
Covenant records exist inside the loan origination system. The difficulty is that they have to be populated by a person reading the credit agreement, and kept accurate as amendments execute, which is a document problem rather than a platform problem.
nCino describes itself as a single, intelligence-driven platform covering customer onboarding, deposit account opening, loan origination, underwriting, and portfolio management, with credit portfolio management capabilities including continuous credit monitoring and detecting credit deterioration earlier. Covenant records live on the loan, which is the right architecture, the loan file in the system of record should be complete.
What varies by institution is how those records get populated. In most implementations the covenant terms are keyed at closing from the credit agreement. The threshold generally survives that process. The defined terms that determine the calculation, the step-down schedule, the equity cure cap, and the carve-outs frequently do not, and the update after the third amendment is the one that most often gets missed. That is not a criticism of the platform; it is a description of what manual data entry does to complex source material.
The options
Option 1: Invest in the process, not the tooling
Keep covenant tracking where it is and fix the inputs. Make covenant data entry a defined step with a second reviewer. Make amendment intake a mandatory closing checklist item. Record section references alongside every covenant so verification is fast.
Reasonable when: covenant packages are straightforward, amendment volume is low, and the portfolio is small enough that a defined manual process is sustainable. This is a genuine option and costs nothing.
Limits: it does not scale with volume or complexity, and it remains dependent on individual diligence. It also does not produce reproducible calculation evidence unless you separately build that.
Option 2: Extend within the Salesforce platform
Because nCino is delivered as a managed package on Salesforce, institutions can extend it using platform conventions, custom objects, flows, validation rules, or a partner-built component.
Reasonable when: you have in-house Salesforce capability, the gap is workflow or reporting rather than document interpretation, and staying inside one platform is a strategic priority.
Limits: configuration improves how covenant data is presented and routed. It does not change where that data comes from. If the underlying issue is that the covenant terms were never fully extracted from the agreement, a better interface on top of incomplete data does not resolve it. This option also creates ongoing maintenance you own. See covenant monitoring on Salesforce.
Option 3: Add a specialized covenant layer
Keep nCino as the system of record and run a covenant intelligence layer alongside it, one that reads the credit agreements directly, produces structured covenant records with defined terms intact, tests them, manages exceptions, and writes results back into nCino as native covenant records.
Reasonable when: covenant packages carry real complexity, amendment traffic is meaningful, you have a back file whose covenant terms were never fully captured, or you need compliance determinations that can be reproduced from stored inputs for examination.
Limits: it is another vendor, another security review, and another integration to own. The back file extraction is a real project. If your covenant work is simple, the added surface area may not be worth it. Mechanics are on AI-powered covenant monitoring for nCino, and the head-to-head framing on CovenantFlow vs. nCino.
Option 4: Keep the parallel spreadsheet
Many institutions running nCino still keep a covenant workbook, because the platform record holds the threshold while the workbook holds the actual calculation.
Reasonable when: it is an explicit, documented arrangement with one clearly authoritative source.
Limits: two systems holding covenant data with no synchronization will diverge, and the loan file in the system of record becomes the incomplete one. This is the most common arrangement and the least deliberate. See covenant tracking in Excel.
The option that usually is not one
Replacing nCino to improve covenant monitoring. A core platform migration is a multi-line-of-business undertaking that touches origination, credit workflow, and the daily working surface for every commercial lender in the institution. Absorbing that to close a covenant data gap is a poor trade, and any vendor encouraging it should be asked why.
How to choose between the four
- If you cannot currently answer which covenant terms are we testing against, and how do we know they match the executed documents, the problem is data provenance, and options 1 or 3 address it. Option 2 does not.
- If the terms are right but the work is slow, the problem is workflow, and options 2 or 3 both help.
- If an examiner has raised how determinations are evidenced, the problem is reproducibility, and only option 3 addresses it without a build.
- If none of these describe you, option 1 is the correct answer and you should not buy anything.
FAQ
Frequently asked questions
- What are the alternatives for covenant monitoring if we run nCino?
- Four realistic routes: keep covenant tracking inside nCino and invest in the process that populates it; extend nCino with Salesforce-native configuration or a partner build; run a specialized covenant layer alongside nCino that extracts covenants from documents and writes results back; or keep a spreadsheet process running in parallel. Each is defensible in different circumstances, and replacing nCino itself is rarely the sensible answer.
- Do you have to replace nCino to improve covenant monitoring?
- No, and it is usually the wrong move. nCino is a system of record covering onboarding, origination, underwriting, and portfolio management. Covenant depth is a narrower problem, and replacing a core platform to solve it means absorbing a large migration to address a specific gap. Adding a covenant layer alongside it is a substantially smaller decision.
- What is the actual gap teams are trying to close?
- Almost always the same one: covenant records exist in the platform but have to be populated by someone reading the credit agreement, and kept current as amendments execute. The threshold usually survives that process. The defined terms, step-downs, equity cure caps, and carve-outs frequently do not, and neither does the update after the third amendment.
- Can a covenant layer write back into nCino?
- Yes. CovenantFlow writes confirmed covenants into nCino as native covenant records with an idempotency key so repeated syncs do not create duplicates, and current values refresh on those records as borrower data arrives. A Lightning Web Component surfaces the covenant table on the nCino Loan record so bankers do not have to switch applications.
Keep going
Related reading
Integration
nCino
A specialized covenant layer on top of the system of record, not a replacement for it.
Comparison
CovenantFlow vs. nCino
System of record versus specialized covenant layer. The two are not substitutes.
Solution
Covenant Data Extraction
Turning unstructured loan documents into covenant records a system can test against.
Alternative
Excel Covenant Tracking
Spreadsheets are the right answer for a while. Here is where the line usually is.
Back to Alternatives.
See how CovenantFlow automates covenant monitoring
Move from loan documents and borrower reporting requirements to structured covenant intelligence, compliance workflows, and portfolio visibility.