Puerto Rico Agent and Address Mismatch: A Lender Review Workflow

Executive Summary: An agent or address mismatch should begin a review, not end a decision. Cobalt's current Puerto Rico field matrix documents agent and address context where returned.^[1] That can be useful evidence when compared with an application. It is not proof that a submitted value is false, that a business committed fraud, or that a lender should approve or decline a file. The useful operating rule is simple: preserve the submitted value, select the right Puerto Rico entity before comparing it, retain the returned value and source context when available, and send a material difference to the lender's named exception route. This makes the mismatch inspectable instead of hiding a policy decision behind one opaque flag.

Why is a mismatch not a verdict?

Two values can differ for many reasons that are not established by the comparison alone. The values can come from different records, the team may not have selected the correct legal entity, a returned field can be absent or incomplete, or the application and state record can use different context. The comparison exposes a question. It does not resolve the question.

Puerto Rico's Department of State administers the public Registry of Corporations and Entities.^[2] The registry is a state source, while the application is a lender-file source. Each must retain its own provenance. Treating one as automatically superior would discard the very evidence a reviewer needs to investigate the difference.

This boundary also matters for control and ownership claims. Public registry information, officer context, and beneficial ownership are different data questions. FinCEN's CDD materials address ownership and control in a distinct regulatory context.^[3] An agent or address comparison should never be relabeled as ownership proof.

What should be selected before any comparison?

Select the legal entity record first. Retain the submitted legal name, Puerto Rico search scope, any identifier supplied, the selected legal title, and the reason the record was selected. Puerto Rico's public search provides both a corporation-name and registration-number route.^[4] If the team cannot establish a selected record, it should route an identity exception before comparing an agent or address value.

This sequence prevents a common error: a state value may be accurate for a different entity with a similar name. The comparison is meaningful only after the system can show which record it is comparing with the application. An unselected record should not produce a mismatch conclusion.

For the wider entity-selection boundary, read Puerto Rico Business Entity Verification: What Alternative Lenders Need to Know. The published pillar explains why a registry lookup is evidence, not a complete underwriting decision.

What should the case record preserve?

Store the values and their sources separately. A later reviewer should be able to see what was submitted, what Puerto Rico returned, whether a field was available, and what the lender decided to do with the difference.

Cobalt coverage guidance treats jurisdiction, field depth, latency, and freshness as separate dimensions.^[5] The same discipline applies here. A documented field belongs in a comparison when returned, but its availability does not make it a universal record-level promise.

How should a mismatch route work?

The route should be explicit. First determine whether the comparison can be made. Then preserve both values. Then apply the lender's materiality rule. If the rule calls for review, assign an owner and state the evidence question that the owner must answer. The route should never leap directly from `different` to `fraud` or `decline`.

{
  "jurisdiction": "pr",
  "submittedAddress": "APPLICATION_VALUE",
  "returnedAddress": "REGISTRY_VALUE_IF_AVAILABLE",
  "submittedAgent": "APPLICATION_VALUE_IF_COLLECTED",
  "returnedAgent": "REGISTRY_VALUE_IF_AVAILABLE",
  "exceptionReason": "registry-application-mismatch",
  "lenderDisposition": "review-required"
}

This is an illustrative case shape, not a claim about a live Puerto Rico response. The important design choice is that the returned observation and the lender-owned outcome occupy different fields. NIST log-management guidance supports retaining source context and changes in a form that later review can reconstruct.^[6]

Which exception reasons should be visible?

Use reasons that describe the evidence condition rather than a presumed cause. Examples include `entity-not-selected`, `agent-field-not-returned`, `address-field-not-returned`, `submitted-value-differs`, `source-context- needs-review`, and `policy-threshold-unclear`. A named owner can then decide whether the case needs corrected input, an alternate source, document review, or policy clarification.

• Entity not selected: resolve identity before comparing values.

• Field not returned: preserve Unknown and use only the approved alternate

control if policy requires one.

• Submitted value differs: retain both values and let a reviewer apply the

lender's materiality rule.

• Source context needs review: identify whether the values concern the

same legal entity and the same comparison question.

• Policy unclear: ask the policy owner to define the route instead of

turning a technical comparison into an unapproved rule.

The Puerto Rico Department's assistance route is available for corporate service questions.^[7] It is a state-service resource, not a replacement for a lender's exception policy or a finding about the business.

How should an underwriter investigate a material difference?

Start with the selection evidence. Confirm the submitted name and jurisdiction, the selected Puerto Rico entity, and the source of each compared value. Then ask the narrow policy question: does this difference require more evidence for this file? A reviewer may request clarification, use an approved alternate source, or follow a documented document branch. The article does not prescribe which action every lender must take.

The reviewer should record the answer rather than only selecting a final status. For example: `address is application mailing context; registry value retained as agent address; policy does not require further source` is a reconstructable reason. `Mismatch cleared` is not. The first preserves evidence and policy; the second hides both.

What should engineering test before automation?

Test the comparison logic with authorized representative records. The test should prove that the system preserves uncertainty and does not generate a verdict from an incomplete field.

1. Test entity selection. Confirm no comparison result is created until a

record is selected or the system explicitly records an identity exception.

1. Test field absence. Confirm a missing agent or address field becomes

Unknown rather than a failed comparison.

1. Test a difference. Confirm both values, their sources, and the reason

for review remain visible.

1. Test the policy branch. Confirm the materiality rule, owner, and next

action are stored separately from the registry observation.

1. Test the audit trail. Confirm a later reviewer can reconstruct input,

source, comparison, policy, and disposition.

State registration systems use their own records and requirements, as the National Association of Secretaries of State notes.^[8] That makes a jurisdiction-scoped, evidence-first test more reliable than a universal assumption about what an agent or address field means.

How should a lender measure this exception queue?

Measure operational conditions, not unsupported fraud outcomes. Count how often a record is not selected, how often a relevant field is absent, how often a comparison enters review, which policy reasons recur, and how long a case remains unresolved. These measures tell the lender whether its own comparison rule needs clarification or a different source path.

Do not treat the counts as a statement about all Puerto Rico entities or as proof that an address mismatch predicts a particular result. The data belongs to the lender's authorized workflow and current product observation. Review it to improve the rule, then retest with the source boundary visible.

How does Cobalt fit without making a mismatch decision?

Cobalt provides documented Puerto Rico registry context where fields are returned. The lender owns input collection, entity selection, comparison thresholds, exception routing, record retention, and the final action. Cobalt does not decide whether a difference is fraudulent, material, or disqualifying.

That division makes the workflow safer to automate. The system can surface a comparison and preserve evidence without claiming that a public registry field is a complete identity, ownership, address, or underwriting answer.

What should a risk leader do next?

Define the mismatch route before making Puerto Rico agent or address context a live decision input. Name the submitted value, selected entity, returned value, source trail, materiality rule, exception reason, owner, and closure evidence. Treat absent fields as Unknown. Refresh the route when the coverage observation or a relevant state process changes.

The result is a controlled comparison: useful for identifying a question, honest about its limits, and never confused with a verdict about the business.

How should a policy owner define a material mismatch?

The policy owner should define materiality as a question about the lender's evidence need, not as a universal claim about agent or address information. A useful rule identifies the comparison being made, the type of source that supplied each value, the evidence condition that triggers review, the owner of the review, and the permitted closure paths. It does not simply say that all differences are bad or all matches are sufficient.

For example, a lender can distinguish between an absent registry field, a value that appears different after format normalization, a value attached to an unselected entity, and a clear difference on an already selected legal record. Those are different operational states. They may have different owners and different approved next steps. A rule that records the state prevents engineering from applying one broad `mismatch` label to every condition.

The policy should also state what a reviewer is deciding. Is the question whether the application is tied to the selected legal entity? Whether an alternate source is required? Whether a document branch is necessary? Or whether the comparison is outside the lender's decision scope? The answer is a lender policy decision. The Puerto Rico field is input to that decision, not the decision itself.

How should formatting differences be handled?

Store the original submitted and returned values before any comparison logic normalizes them. A system may create a normalized comparison representation for consistent routing, but it should not erase punctuation, abbreviation, unit, or ordering differences from the source record. A reviewer needs access to the exact values that generated the exception.

Normalization should produce a transparent event: what rule was applied, which source values were transformed, whether the transformed values still differed, and whether the lender policy treats the remaining condition as reviewable. The purpose is not to manufacture a match. It is to make the comparison reproducible. When the system cannot safely compare the values, it should use an explicit `comparison-not-determined` state.

This preserves the source boundary. A registry field may be a business or agent context, while an application may record a mailing or operating context. The article does not claim which source should win. It requires the lender to record the distinction and decide under its own policy what additional evidence is appropriate.

What should a reviewer be able to see on one screen?

The review surface should show the minimal evidence chain, not a black-box score. It needs the submitted application value and timestamp, Puerto Rico lookup scope, selected entity record, returned agent or address field when available, source trail when available, comparison result, policy rule version, exception reason, current owner, and the history of actions taken.

The reviewer should also see what is Unknown. If an agent field was not returned, the surface should say that rather than showing an empty value beside the word `match`. If the entity record was never selected, the surface should block or label the comparison rather than presenting a result that looks authoritative. If an alternate source was used, retain it as a separate observation rather than overwriting the Puerto Rico record.

This design makes delegation safer. An operations teammate can explain why a case is pending without claiming that the business failed verification. A policy owner can review recurring reasons without reading raw data from every file. An auditor can reconstruct the route from evidence, policy, and action.

Where does the mismatch route sit in the underwriting waterfall?

It sits after identity selection and before any lender action that relies on the comparison. First, the system captures the application claim. Second, it performs the Puerto Rico lookup when the approved route calls for it. Third, it selects or fails to select a legal entity. Fourth, it compares relevant values only when the entity and fields support comparison. Fifth, it enters the lender-owned match, review, alternate-source, or unresolved route.

This order avoids a costly shortcut. It does not ask a comparison field to perform identity selection, ownership verification, or underwriting. It makes each process visible enough to test. The lender can then improve an exception rule based on observed operational gaps without changing the historical source record or pretending that Cobalt supplied a final decision.

When should the route be refreshed?

Refresh the route when the Puerto Rico coverage observation changes, when representative permitted tests reveal an unhandled comparison state, or when the exception queue repeatedly produces the same unclear question. The review note should name the source checked, the date, fields observed, policy effect, and owner. If the source boundary changes, update the policy before new files are evaluated as though the old assumption still applied.

This is a normal control, not a claim that earlier records were false. It keeps the product observation, the lender's materiality rule, and the operational review surface aligned over time.

What does a complete mismatch closure record contain?

Close an exception with evidence, not a vague label. The closure should retain the original submitted value, the returned Puerto Rico value when available, the selected entity, source context, the comparison condition, the policy rule applied, the person or system that acted, the time of the action, and the reason the lender considered the case resolved or left it unresolved. If an alternate source or document was used, preserve it as an additional observation with its own provenance.

The closure may say that the policy accepted a documented difference, that an approved alternate source resolved an identity question, that the application was corrected, or that the file needs further evidence. It should not say that the agent, address, or business was "verified" unless the lender's defined control actually supports that narrow claim. It should never restate a source comparison as a general fraud or ownership conclusion.

This level of detail protects the lender when the case is revisited. It lets a new reviewer see what was known at the time, which evidence was missing, and why the previous owner chose the next action. It also permits policy analytics: the team can see whether most conflicts arise from missing fields, entity selection, formatting, or a genuinely unresolved question.

How can a team train against misuse of the mismatch flag?

Use short controlled examples. Give reviewers a selected entity with a field not returned, a value that differs only after source formatting, a comparison between an unselected entity and an application, and a material difference that requires an alternate source. Require the reviewer to state the evidence condition, source boundary, policy trigger, and next owner. Do not train them to guess a business outcome from a label.

The training objective is consistent routing, not certainty. If reviewers can explain why the system knows less than a final verdict, they are more likely to preserve Unknown values, open the right exception, and return decisions to the lender policy owner when required.

What is the minimum safe comparison rule?

Do not compare before selecting an entity. Do not treat a missing field as a failed match. Do not overwrite either source value. Do not convert a difference into a fraud, ownership, residence, or funding conclusion. Preserve the source context, apply the lender's materiality rule, and record a named owner for any exception. This small rule is enough to keep a new Puerto Rico field useful without letting an automation shortcut exceed the evidence it has received.

It also supports future review: when source context or policy changes, the lender can see exactly which observation and rule governed the earlier case. That record protects evidence quality while allowing the operational process to evolve without rewriting the original comparison or silently changing prior case outcomes.