How to Build a Puerto Rico KYB Exception Queue

Executive Summary: A Puerto Rico registry difference should enter a KYB exception queue as an evidence condition, not as a binary verdict about the business. A returned field may differ from an application claim. A field may be missing. A record may not be safely selected. Each condition has a different cause and a different next step. Cobalt's coverage guidance warns that documented field availability varies by jurisdiction and does not promise population for every record.^[1] The queue should keep that source limit visible while giving the lender a fast, owned route for deciding what additional evidence, if any, is needed. Current Puerto Rico coverage documents registry context such as status, entity, jurisdiction, agent, address, officers, documents, source URL, and screenshot where returned.^[2] The queue is not a claim that those fields always appear or that any difference is material. It is a lender-owned control that records what was observed, what the active policy required, who owns the review, and how the case closed.

What belongs in an exception queue?

Place a file in the queue when a named evidence or policy condition needs a separate route. Common categories are `entity-not-selected`, `field-not-returned`, `comparison-not-possible`, `application-value-different`, `source-context-needs-review`, `alternate-evidence-required`, and `policy-trigger-unclear`. The category should name the actual state. It should not say the business is fraudulent, inactive, invalid, or declined unless a separate source and authorized lender decision establish that conclusion.

This is more than naming. A clear reason code tells the queue owner what to do. An entity-selection exception may need additional identifiers. A missing field may require an Unknown-state policy. A difference may require comparison evidence or an approved alternate source. An unclear policy trigger may need a risk owner, not a new data request. One generic failure label cannot distinguish those work types, so it creates avoidable delay and weak audit records.

Select the entity before comparing a field

The Puerto Rico public registry supports searches by corporation name and registration number.^[3] Before the queue evaluates a status, address, agent, jurisdiction, or officer field, retain the application input, Puerto Rico scope, submitted identifier, selected legal title, and selection rationale. If the evidence does not support selection, route identity review. Do not compare a candidate record with an application and call the result a mismatch.

Puerto Rico's Department of State administers the public Registry of Corporations and Entities.^[4] That is the source context for a returned field. It does not establish that the first result is the applicant or that the record answers every policy question. Selection evidence is therefore the first queue field, not a detail buried in an attachment.

Separate source evidence from lender policy

The source layer should store the query, selected record, returned fields, source trail when available, and retrieval time. The policy layer should store the condition evaluated, policy version, required action, owner, target time, and closure standard. A comparison layer can connect the two by showing the application claim, source value, and result state. These layers must not be collapsed into one status. They answer different questions and change at different times.

For example, an agent address might differ from an application address. The source layer says what the selected record returned. The comparison layer says the two values were not the same. The policy layer decides whether that difference is immaterial, requires clarification, or needs another approved source. Cobalt did not make that policy choice, and the registry did not make a lending decision. The queue must preserve those boundaries.

Create a queue ticket with a complete evidence packet

Each ticket should include a stable case reference, application claim, query scope, selected-entity state, requested field, returned source value or explicit Unknown, source URL or screenshot when returned, retrieval time, comparison result, reason code, policy version, owner, next evidence request, and closure criteria. The goal is not a large form. The goal is a ticket that lets the owner act without searching through disconnected screens or guessing what happened before the queue opened.

Add a source-limit field. It can say `field-not-returned`, `selection-not- established`, `source-URL-not-returned`, or another observed limitation. This prevents a queue note from turning source absence into a negative conclusion. It also lets a manager later measure whether exceptions come from inputs, selection, coverage, policy, or operations.

Route by evidence state, not a generic risk label

This table also gives engineering an implementation contract. It makes clear that a technical state must survive long enough for policy to act on it. A binary rule that immediately converts any state into a decline cannot explain which evidence was absent, what comparison was attempted, or which human or policy authority supplied the final answer.

Define ownership and service expectations

Assign each reason code to an owner before the queue receives production cases. Identity exceptions may belong to underwriting operations. Mapping or source format questions may belong to engineering or data governance. Policy ambiguity may belong to risk or compliance. An alternate-evidence request may belong to a case reviewer. The case record should show the owner, target time, handoff history, and what event allows closure.

Ownership is a control against silent abandonment. A queue that only shows age and status may look manageable while cases wait because nobody owns the next evidence action. Conversely, a queue that tracks owners but not evidence state can make a person responsible for resolving a question the record never defined. The useful ticket joins both: a precise evidence condition and a named action owner.

Keep alternate evidence as a second observation

When policy requires another document, a different state record, applicant clarification, or manual review, store it as a separate evidence observation. Preserve why it opened, what source was used, the retrieval time, what it established, and who reviewed it. Do not overwrite the original Puerto Rico field, difference, or Unknown state. The alternate evidence may resolve the policy question, but it does not change what the original response established.

Puerto Rico's public corporation forms and assistance routes can help operators locate official processes.^{[5] [6]} They do not prescribe the lender's permitted evidence list or closure standard. The lender must define that standard before the queue asks an operator to collect material.

Give the reviewer a chronological record

The review screen should show events in order: application input, search, selection, returned field, comparison, queue opening, policy action, alternate evidence, review, and closure. Chronology prevents a later document from being misread as part of the original Puerto Rico response. It also allows a manager to see whether an exception arose from data, process, or a policy decision.

NIST guidance supports retaining context that allows review and reconstruction.^[7] For a KYB exception, reconstruction means a new reviewer can identify what the system observed, what it could not establish, why the lender opened the queue, and which evidence ultimately closed the file. It does not require claiming that any single field or artifact is a complete answer.

Test the queue before automating it

Use permitted representative tests for an entity selected with matching fields, a selected entity with a difference, a selected entity with a missing field, an unselected candidate, an unfamiliar status, and a policy that accepts Unknown for one use but needs another source for another. Confirm that each state opens the correct ticket, retains source context, assigns the right owner, and does not generate a negative business label by default.

Then run a replay test with a reviewer who did not build the workflow. They should find the original input, selected record, exact evidence state, policy trigger, alternate evidence, closure, and audit history. If they cannot, fix the event linkage or ticket fields. Do not fix it by adding a stronger final status that hides the missing reasoning.

Measure the queue as an operational control

Measure tickets by reason code, selected-entity rate, field-return rates in authorized tests, alternate-evidence use, ownership handoff, time to first action, time to close, reopened cases, and closure reason. Segment by policy version and use case. These measures show whether a workflow needs clearer inputs, better testing, a different evidence rule, or capacity changes. They do not establish that a particular Puerto Rico business is risky or compliant.

When a pattern repeats, investigate the control. High selection exceptions may call for input validation. Repeated field absence may call for a clearly defined Unknown path. Long aging may call for a new queue owner. High policy ambiguity may call for a narrower rule. The result is an exception system that learns from evidence states without converting them into business judgments.

Keep public and legal context in scope

State registration systems have state-specific records and requirements.^[8] General corporate-law material can provide background, but it does not prove a case-specific status, mismatch cause, or policy result.^[9] Use such sources to understand context, not to replace the selected-record evidence and lender-owned decision trail in an individual file.

Where Cobalt fits

Cobalt provides documented Puerto Rico registry context where returned. It can give a lender comparable source facts and source references for a controlled review workflow. It does not decide whether a mismatch is material, which alternate evidence is acceptable, who owns a queue, or what final action a lender takes. Those responsibilities remain in lender policy.

This boundary makes the queue more useful. It gives the team a structured way to handle legitimate uncertainty and differences without pretending that a registry response or an integration made a risk, compliance, ownership, or funding decision.

What should a risk leader do next?

Publish a small, named reason-code set before connecting Puerto Rico fields to a binary workflow. Define the selection standard, evidence states, comparison rules, policy trigger, alternate evidence, owner, service target, and closure criteria for each code. Test every route with permitted records and sample closed cases for replay quality.

The queue will then accelerate the right work: it routes evidence gaps to the people and policies that can resolve them while keeping the original Puerto Rico observation truthful and visible.

Start with an exception taxonomy that can be audited

Do not allow teams to create free-form exception labels in the first version of the queue. A limited taxonomy makes the work measurable and makes it possible to compare similar cases. Define each code with four parts: the evidence state that opens it, the selection requirement, the policy condition, and the allowed next action. For example, `address-difference` may require a selected entity, two observed addresses, a named policy use case, and a choice between no action, clarification, or approved additional evidence. It does not imply that either address is false.

Document codes that must never be inferred. `ownership-not-established` is not the same as no owner. `status-not-returned` is not the same as inactive. `entity-not-selected` is not the same as a nonexistent business. These boundaries make queue training clearer and stop a familiar operational shortcut from converting absent or incomplete information into a business assertion.

Puerto Rico's public corporations service is a useful official source context, but the actual case taxonomy and lending action remain the lender's responsibility.^[10]

Put a decision clock on the action, not the evidence

Set service targets for ownership and follow-up actions, but do not claim the underlying public record will change on the queue's schedule. A ticket can have `owner-assigned-by`, `first-action-by`, `evidence-requested-at`, and `review-due-by` values. These are operational commitments. They help a lender manage deal velocity and prevent a case from disappearing, yet they do not make the source record more complete or prove that an applicant caused the delay.

This distinction is useful when leadership reviews aging. A long-lived ticket could reflect an unselected entity, an unavailable field, a policy question, a pending document, or a capacity issue. The queue should reveal which event is waiting and who owns it. A single age number without a reason code encourages the wrong fix, such as pressuring an operator to close a file before the required evidence route is complete.

Record closure as a policy event

Closure must answer more than `resolved`. Record the reason for closure, the evidence used, the policy version, the responsible reviewer, the time, and any remaining limitation. A file may close because the original comparison was not required by policy, because an approved source answered the question, because the applicant clarified an input, or because a named policy owner made a disposition. These outcomes should not overwrite the original registry state.

The closure reason provides a feedback loop. If many cases close as `not-required-by-policy`, the initial routing condition may be too broad. If many cases close through an alternate source, the lender may need a clearer pre-queue rule or a defined evidence route. If many cases cannot close because policy is unclear, that is a governance finding, not a source defect. The queue becomes valuable when it exposes those patterns rather than hiding them inside completed counts.

Build evidence packets for handoffs between teams

An exception should not lose context when it moves between underwriting, operations, compliance, and engineering. Give every handoff a compact evidence packet: the case ID, reason code, current owner, selected-entity state, field or comparison at issue, raw source context, retrieval time, policy version, work already attempted, next question, and required closure evidence. The next team should not have to reopen a search merely to understand why the ticket exists.

Handoff packets also protect source boundaries. Engineering can investigate a mapping or response state without deciding an underwriting outcome. Compliance can review a policy trigger without changing the raw source observation. Underwriting can request an approved evidence item without recasting it as a registry fact. Each team sees the part it owns and can return a documented event to the case history.

Review queue quality through sampling

Take a representative sample of open and closed tickets each week. Check whether selection was supported before comparison, whether the reason code matched the evidence state, whether the policy version was present, whether an alternate source was retained separately, whether ownership moved correctly, and whether closure describes what actually happened. Sample both fast closures and aged tickets. Fast closures can hide premature defaults, while aged cases can reveal unclear policy or missing capacity.

Use the sample to improve the route. If staff consistently choose a generic reason code, narrow the choices or update training. If reviewers repeatedly need evidence that the ticket did not request, adjust the evidence packet. If closure cannot be explained from the record, require a more precise closure event. The objective is not more documentation for its own sake. It is an exception decision that another competent reviewer can understand and verify.

Protect the queue from scope creep

The queue should not become a catchall for unrelated financial crime, ownership, credit, sanctions, or lien conclusions. A Puerto Rico registry observation can trigger a separate control when lender policy requires it, but the ticket must identify that control and preserve its distinct source boundary. Do not turn officer context into beneficial ownership, a filing date into compliance, or an address difference into fraud. When another verification layer is needed, open a linked but separate evidence route.

This boundary keeps the queue usable. Reviewers can see what the Puerto Rico record did establish and which additional control owns the next question. It also prevents reporting from falsely attributing a conclusion to Cobalt or the public registry when the conclusion came from another source or a lender rule.

Define the minimum safe queue contract

Before launch, require a stable ticket ID, application context, query scope, selected-entity state, evidence state, source retrieval time, comparison result when applicable, reason code, policy version, owner, target action, alternate evidence link, closure record, and audit history. Prohibit negative defaults for missing fields and unselected entities. Prohibit overwriting original source observations. Require a named owner for every open ticket.

This small contract creates a system a lender can actually govern. It keeps the Puerto Rico feature in its proper role as registry context while giving the lender a deliberate path for the hard cases that a binary rule cannot explain.

Review the contract whenever source coverage, policy requirements, or queue patterns change. Keep earlier ticket evidence intact so the team can distinguish a changed rule from a changed record response. This preserves accountability across future operational revisions clearly.