Adding Existing Borrowers to Monitoring: Review the Baseline Against the Origination File

Executive Summary: Existing borrowers who are enrolled into ongoing monitoring after they have already been funded create a specific reconciliation task that a fresh applicant never generates: someone has to compare what the monitoring baseline shows today against what the origination file showed on the day the loan closed. This article sets out a one-time enrollment reconciliation step, distinct from the change alerts and cadence decisions that come later, so that changes predating enrollment do not quietly disappear into a new starting point.

What Does A Monitoring Baseline Actually Confirm?

Is the first check a comparison to the origination file?

No. When a business is enrolled in Cobalt Business Monitoring, the first check establishes a baseline, and because it is the baseline it reports no changes.^[1] The API documentation shows the same structure: the first delivered check carries isBaseline: true, hasChanges: false, and an empty changes array.^[2] That baseline is a snapshot of the Secretary of State record on the day the check ran. It is not a diff against the loan file from twelve or twenty-four months earlier, because monitoring has nothing in its own memory to compare it to yet. The comparison only begins with the second check, when the new result is compared against the previous record.^[1]

This distinction matters most for existing borrowers, since a new applicant's baseline and origination search happen close enough in time that the gap is rarely material. An existing borrower enrolled well after funding presents a different situation: the origination file might show a registered agent from three years ago, while the baseline shows whoever the state currently lists. Monitoring will not flag that difference as a change, because from monitoring's perspective there is no prior monitoring record to compare against. The field simply appears as the current value, correctly, with no signal that it moved at some point between funding and enrollment.

Why does "no changes" describe monitoring, not loan history?

The phrase "no changes" in a baseline result is a narrow technical statement about the comparison monitoring is capable of making at that moment, not a broader claim about the borrower's history. Related reading on point-in-time KYB versus ongoing monitoring makes the underlying distinction explicit: an origination file proves what the registry showed on one date, and it cannot show whether the entity changed after funding.^[3] The same logic runs in the other direction for an existing borrower. The baseline proves what the registry shows on the enrollment date. It says nothing about whether the entity changed between funding and enrollment, because no monitoring check existed during that window to observe it.

Treating "baseline, no changes" as equivalent to "this borrower has been stable since origination" is the exact assumption this article is built to correct. We recommend reviewers read the phrase literally: the monitoring comparison found nothing to compare against yet. Whatever happened to the registered agent, the address, or the entity status in the interim is a separate question, answerable only by pulling the origination-era record and setting it beside the baseline manually.

How Should A Reviewer Compare Two Dated Records?

What are the two source documents in this comparison?

The reconciliation requires two dated observations, not one. The first is the origination file, meaning whatever Secretary of State search or document was captured and stored at the time the loan was underwritten. The second is the monitoring baseline captured at enrollment. Both are point-in-time records from the same category of source, a state registry, but pulled on different dates, and a portfolio review policy should treat them as two separate exhibits rather than one continuous record.^[3]

A workable approach is to pull the origination file's stored fields, whatever was captured at that time such as entity status, registered agent name, and address, and place them next to the baseline's equivalent fields. New York's own entity database illustrates the kind of fields a state registry typically carries: current entity name, date of organization, jurisdiction, county location, service of process address, registered agent if any, and current status.^[4] Cobalt's monitored categories track a similar set, covering business status, registered agent, business identity, addresses, compliance items, identifiers, and contact fields.^[1] Reviewers comparing origination to baseline should focus on fields that appear in both records, since incomplete fields in the origination file, common when the file predates fields Cobalt currently tracks, cannot be reconciled against a baseline that includes them.

How does incomplete origination data limit the comparison?

Origination files vary in completeness depending on when the loan closed and what was captured at the time. A file closed several years ago might have only a printed certificate of status, without machine-readable fields for every category the current baseline reports. New York's Division of Corporations states that its database information is updated daily, and cautions that because the Department relies on information provided to it, the completeness or accuracy of that information cannot be guaranteed.^[4][5] A reviewer working an existing borrower's file should expect gaps, not treat a missing field in the older record as evidence that nothing existed there, and should log the gap itself as part of the reconciliation rather than skipping the field entirely.

What Does A Worked Reconciliation Look Like?

How would this play out for a hypothetical existing borrower?

Consider an illustrative scenario, not an observed transaction. Borrower A operates as Entity B, a limited liability company funded eighteen months ago. The origination file for Entity B, captured at closing, lists the registered agent as an individual, the entity status as active, and a specific mailing address. Servicing decides to enroll Entity B in ongoing monitoring now, well after funding, using the business name and state on file, which are the enrollment inputs the documentation describes alongside an optional SOS ID.^[2]

The enrollment produces a baseline check. That baseline reports isBaseline: true, hasChanges: false, and shows the current record: entity status active, but the registered agent now listed as a commercial registered agent service rather than the individual named in the origination file, and a different mailing address. Monitoring does not flag this as a change, because there is no prior monitoring observation for comparison.^[1] A reviewer relying only on the baseline result would see "no changes" and move on. A reviewer who pulls the origination file and sets it beside the baseline sees a registered agent swap and an address change that occurred sometime in the eighteen months between funding and enrollment, with no record of exactly when.

This is the reconciliation gap the exercise is meant to close. Neither fact is wrong. The baseline correctly reports no changes because monitoring only started comparing from that point forward. The origination file correctly reported the state of the record at closing. The absence is in the space between the two dates, which monitoring was never running during and cannot retroactively fill in.

What should the reviewer record about this gap?

The reviewer should document the discrepancy as an enrollment-time finding, separate from any future monitoring alert. A workable format states the origination value, the baseline value, the date range in which the change presumably occurred, and whether the change alone warrants a servicing follow-up such as a direct call to the borrower or a fresh document request. This finding belongs in the loan file as a distinct entry, not merged into the ongoing monitoring change log, because it originates from a manual comparison rather than from a Cobalt-detected change event.

What Decision Table Should Guide Enrollment Review?

Which enrollment scenarios call for different reviewer actions?

The following decision table sets out a proposed review policy for reconciling origination files against monitoring baselines at enrollment. This is a customer-owned control, not a Cobalt feature or output.

How should severity labels from later monitoring differ from this table?

It is worth being explicit that the severity levels Cobalt assigns to changes, such as Critical for an entity moving between active and inactive status,^[1] apply only to changes detected between two monitoring checks after the baseline. They do not apply to the enrollment-time reconciliation described above, because that reconciliation is a manual comparison the reviewer performs once, outside the monitoring comparison entirely. Related reading on storing monitoring events underscores the same separation, noting that the source event should remain evidence about a state record while the lender's interpretation stays in separate customer records.^[6] The decision table above governs the one-time reconciliation. Severity labels govern what happens after that, once monitoring has two checks to compare.

What Reviewer Worksheet Supports This Reconciliation?

What fields should the worksheet capture?

A usable worksheet keeps the reconciliation auditable and repeatable across a portfolio. We recommend the following structure, completed once per existing borrower at enrollment:

• Borrower identifier. The internal loan or account number, plus the entity name and state used for the monitoring enrollment lookup.

• Origination file date. The date the origination Secretary of State record was captured, pulled from the closing file rather than estimated.

• Baseline check date. The date the monitoring baseline was delivered, taken from the checkedAt timestamp in the baseline payload.^[2]

• Field-by-field comparison. Entity status, registered agent name, and address at minimum, with origination and baseline values entered side by side.

• Discrepancy disposition. For each field that differs, a short note on whether it was escalated, logged as routine, or flagged as an origination data gap.

How should this worksheet be stored and reused?

The worksheet should be saved as a dated record tied to the loan file, separate from any future monitoring change log, so a later reviewer can see that the enrollment-time comparison happened and what it found. Related reading on storing monitoring webhooks for a defensible history recommends keeping the provider's observation as immutable evidence and linking it to separate records for account context and reviewer disposition.^[6] The same principle applies to this worksheet: it is customer-owned recordkeeping, not a Cobalt output, and it should not be overwritten when later monitoring checks arrive. Below is an illustrative customer-owned review record showing the kind of structure a servicing team might store internally; the dates and values are invented.

{
  "recordType": "illustrative customer-owned review record",
  "loanId": "application-example-1",
  "entityReviewed": "Entity B",
  "originationFileDate": "example-origination-date",
  "baselineCheckDate": "example-baseline-date",
  "baselineMasterRequestId": "example-master-request-id",
  "fieldComparison": [
    {
      "field": "registeredAgentName",
      "originationValue": "Individual Name on File",
      "baselineValue": "Commercial Registered Agent Service",
      "disposition": "flagged for servicing follow-up"
    },
    {
      "field": "entityStatus",
      "originationValue": "active",
      "baselineValue": "active",
      "disposition": "logged as match"
    },
    {
      "field": "mailingAddress",
      "originationValue": "example-origination-address",
      "baselineValue": "example-baseline-address",
      "disposition": "requested updated borrower documentation"
    }
  ],
  "reviewerNotes": "Origination file did not capture agent resignation history; gap logged, not treated as an active change event."
}

A workable operating principle: treat every enrollment-time baseline as an invitation to reconcile, not a certificate that nothing happened before it.

What Alternative Approaches Exist Besides A Monitoring Baseline?

Can a reviewer just pull the current record directly?

Yes, and this is often the simplest starting point before enrollment. A direct authority lookup against the relevant Secretary of State's own search database, such as New York's Corporation and Business Entity Database, returns the current entity name, date of organization, jurisdiction, county location, service of process address, registered agent if any, and current status as of the search date.^[4] This gives a reviewer the same kind of point-in-time snapshot a monitoring baseline would produce, without enrolling the business at all. The limitation is the same one that applies to any single pull: it tells you the state of the record on the day you looked, not what it looked like at any point between origination and today. New York's search page also states that the system should not be used to determine the acceptability of an entity name and that completeness or accuracy cannot be guaranteed.^[5]

For a fuller documentary record, a reviewer can request copies of filed documents from the state; New York provides plain copies for $5 and certified copies for $10 by written or online request, which can confirm exactly what was filed and when.^[7] This is heavier than a routine reconciliation typically needs, but it is the right tool when a discrepancy found during baseline comparison needs a documentary answer rather than a database snapshot.

What role do borrower documents and internal file review play?

Borrower-supplied documents, such as a current certificate of status or an updated operating agreement, are a second alternative path. Requesting these directly from Entity B closes the same gap a manual origination-to-baseline comparison surfaces, and it has the advantage of coming from the borrower rather than being inferred from two separate state pulls. The tradeoff is response time and borrower cooperation, which is why a monitoring baseline comparison is often the first step and a document request the escalation.

Internal file review, meaning simply having a servicing analyst open the original closing file and read what was captured, is the most basic alternative and the one the reconciliation worksheet above assumes will happen. None of these approaches require a monitoring product at all. They are worth doing as standalone practices, and they are also the raw material a reviewer needs before a monitoring baseline comparison can mean anything, since the baseline has nothing to be compared against without them.

How Does A Bounded Monitoring Product Fit Into This Bridge?

What does Cobalt Business Monitoring add once reconciliation is done?

Once a reviewer has completed the enrollment-time reconciliation described above, the value of ongoing monitoring is that it removes the need to repeat a manual search-and-compare exercise on a recurring schedule. Cobalt Business Monitoring re-checks a business's Secretary of State record on a cadence the customer sets, between one and thirty days, and delivers the full current record along with a description of any detected changes to a customer-specified webhook.^[1] Enrollment uses a business name or SOS ID, a state, a check frequency, and a callback URL; the enrollment call returns a masterRequestId immediately and the first check is delivered to the callback afterward rather than in the enrollment response.^[2] Every check is posted in the same envelope as the Secretary of State search callback, with the record at results[0] and requestId at the top level, and later checks carry a changes array whose entries use the actions Added, Modified, or Removed.^[2]

This is a documented scope: Secretary of State record checks on the same search layer Cobalt operates across the 50 states, comparing full records field by field, with severity labels attached to detected changes.^[1] The same product description states that entity records move independently of liens, judgments and licensing, which is why UCC filing data and court-record cross-referencing remain separate checks rather than something entity monitoring replaces.^[1] We recommend writing the remaining boundaries into policy as well: sanctions screening and any cash-flow or credit review sit outside this scope, and monitoring cannot retroactively reconstruct what changed between an old origination file and today. The baseline check exists precisely because monitoring only starts comparing from the moment it begins running; it cannot look backward past its own enrollment date.^[2]

What should a portfolio team do differently after understanding this scope?

We recommend building the enrollment reconciliation into onboarding for any existing borrower being added to monitoring after funding, using the worksheet structure above, before treating the monitoring baseline as the operative record for that account going forward. Related reading on setting up monitoring for a loan portfolio recommends deciding which borrowers are in scope and what interval applies before any integration work begins,^[8] and the same discipline applies to the reconciliation step: decide it is required, assign it to a named reviewer, and complete it before the account is treated as fully enrolled. This keeps the origination file, the reconciliation worksheet, and the ongoing monitoring change log as three distinct, dated records rather than one blended narrative.

What Exception Breaks This Pattern?

When does the origination-to-baseline comparison not apply cleanly?

Consider a contrasting case, again illustrative. Suppose a lender originated a loan to a borrower operating as a sole proprietorship rather than a registered entity, or originated against an entity that was later dissolved and re-formed under a new registration before monitoring enrollment. In the sole proprietorship case, there may be no Secretary of State record at all to serve as an origination file. New York's entity database, for instance, covers business and not-for-profit corporations, limited partnerships, limited liability companies and limited liability partnerships, and separately includes assumed-name filings for corporations, limited liability companies and limited partnerships,^[5] so a sole proprietor that has filed neither an entity record nor an assumed name with the state will not appear in the search results monitoring depends on.

In the dissolution-and-reformation case, the entity found at baseline may carry a different SOS ID or filing date entirely from the one referenced in the origination file, because it is, functionally, a different registration even if the business operates under the same name. Cobalt's monitoring documentation notes that a changed filing date is treated as a Critical severity change specifically because it suggests the record now being watched may not be the same registration that was originally underwritten.^[1] At baseline, however, this would not yet register as a change, since there is no prior monitoring check to compare the filing date against.

How should a reviewer handle this exception?

In both scenarios, the standard worksheet comparison breaks down because the two records being compared are not describing the same underlying registration, or one side of the comparison does not exist. We recommend that a reviewer encountering a missing origination entity record, or a baseline showing a different SOS ID or filing date than expected, escalate the account for manual underwriting-style review rather than proceeding with the standard field-by-field reconciliation. The worksheet's discrepancy disposition field should record explicitly that the comparison could not be performed as designed, along with the reason, so the account is not silently treated as reconciled when it was not.

What belongs in a portfolio onboarding policy for this step?

A portfolio onboarding policy for existing borrower enrollment should state plainly that the monitoring baseline is not a substitute for reviewing the origination file, and should require the reconciliation worksheet to be completed and stored before an account is considered fully enrolled in ongoing monitoring. The policy should also specify who owns this task, since related reading on portfolio monitoring setup recommends a named role rather than a shared queue for alert ownership,^[8] and the same logic applies to the reconciliation step itself.

The policy should also address recordkeeping discipline. Documents obtained through related verification workflows may be delivered as links; Cobalt's help documentation describes its document links as time-limited by default, with an extension available on request.^[9] A workable policy directs staff to download and store any such document as part of the loan file rather than relying on a link remaining accessible indefinitely. Because the reconciliation worksheet may reference borrower identifying details, addresses, and other business information, a proposed control is to apply ordinary data minimization discipline to it: keep only what is needed to support the servicing decision, store it securely, and dispose of it according to the lender's retention schedule once it is no longer needed. The Federal Trade Commission's guidance on protecting personal information recommends taking stock of what personal information is held, scaling down retention to what is necessary, and locking down access to sensitive files.^[10] Applying that same discipline to the enrollment reconciliation worksheet keeps this new manual control from becoming its own recordkeeping liability. None of this is a Cobalt feature; it is a proposed internal control layered around a documented monitoring baseline.

If your servicing or portfolio risk team is planning to enroll an existing book into monitoring, bring one real enrollment scenario, the origination file fields you actually captured and the baseline fields you expect, to a session at the Cobalt Intelligence demo page and we can walk through how the baseline payload maps to your reconciliation worksheet.