Executive Summary: Puerto Rico SOS Search should not force a lender to choose between two interchangeable fields. A business name and an SOS ID belong to different points in the same verification record. The name begins the search when the file does not yet hold an accepted Puerto Rico entity record. The SOS ID is the direct input to use again after the lender has selected and retained that record.[1] That distinction keeps a useful API input from becoming an unsupported lending conclusion. Cobalt's Puerto Rico feature accepts both a business name and SOS ID through its existing SOS Search route, but Cobalt is a business-verification data source. The lender still owns match acceptance, credit policy, and every exception decision.[1]
What is the difference between a Puerto Rico business-name and SOS-ID lookup?
Puerto Rico's Registry of Corporations and Entities exposes both a corporation name field and a registration-number field in its own search interface.[2] That is a useful source-of-record distinction for an integration.
• Business name starts discovery. Use the legal name supplied in the
application, with Puerto Rico as the state scope, when no verified state registration number is already attached to the file.
• SOS ID retrieves a selected record again. Use an SOS ID after the
lender's own workflow has tied it to the entity selected from a prior search or source record.
• The two inputs should remain linked. Preserve the submitted name, the
state scope, the selected legal name, and the accepted SOS ID in the case record. A later reviewer needs to see how the identifier entered the file.
• Neither input makes a credit decision. A match can provide registry
evidence. It does not establish ownership, tax identity, lien position, sanctions status, or repayment capacity.
The Puerto Rico Department of State administers the public registry for entities formed in Puerto Rico and entities authorized to do business there.[3] The registry is therefore the right context for a business-registration check, but it is only one layer of a lender's verification process.
When should an application begin with a business-name lookup?
Begin with a business-name lookup when intake has a legal business name but no SOS ID that the lender has already accepted as belonging to the intended Puerto Rico entity. That is the ordinary discovery situation: an application provides a name and state, and the workflow needs to compare the resulting registry record to the file.
Cobalt's release documentation identifies business name and SOS ID as the two Puerto Rico input paths, with `pr` and `puertoRico` as documented state values.[1] The generic SOS API contract also treats `searchQuery` and `sosId` as alternative inputs under a state-scoped request.[4]
An initial name search should leave the lender with a comparison task, not a binary answer. The reviewer or rules engine can compare the returned legal name, status, filing date, entity type, formation and registration jurisdictions, address, and agent fields to the application where those fields are present. The Puerto Rico field matrix marks those fields as available, but availability is not a promise that every record will populate every field.[5]
What should a lender preserve after the name search?
Store the request and its evidence before the file moves forward. A practical record contains:
• Original input. The business name supplied, the Puerto Rico state value,
request time, and the workflow or application identifier.
• Selected registry record. The returned legal entity title and SOS ID,
plus the raw and normalized status where returned.
• Comparison context. Filing date, entity type, formation and registration
jurisdictions, and any fields the lender used in its rule.
• Source evidence. The source URL and a screenshot URL when the response
includes them and the lender requests them.
• Disposition. Accepted record, review required, no result, source issue,
or another lender-defined exception outcome.
This is a recordkeeping pattern, not a regulatory prescription. The public Cobalt coverage guide makes the same operational point: field depth, latency, and freshness differ by jurisdiction, so a team should preserve the evidence behind the field it relies on.[4]
When should a lender reuse a Puerto Rico SOS ID?
Reuse an SOS ID when the lender has already selected the corresponding Puerto Rico record and needs to retrieve that same state record again. Examples include a pre-funding recheck, a follow-up review, or a controlled refresh of the verification evidence.
This is the input-selection rule:
| File state | Input to send | Why | Required control |
|---|---|---|---|
| The file has a business name but no accepted state record | Business name | It starts discovery from the evidence actually supplied at intake | Preserve search terms and inspect returned alternatives or mismatches |
| The file has a previously selected Puerto Rico entity and a retained SOS ID | SOS ID | It directly requests the selected state record again | Preserve the link between the ID, original name, and prior selection event |
| The ID is supplied by the applicant but has not been tied to a selected record | Business name plus lender review | The number is an assertion until it is reconciled with the file and state record | Do not treat the applicant-supplied ID as proof of identity |
| A search returns no result, close alternatives, or an inconsistent record | Do not silently retry into approval | The evidence chain is incomplete | Route to the documented exception process |
The important boundary is provenance. An SOS ID may be more direct than a business-name query, but it is only useful as a stable retrieval key when the lender can show why it belongs to that file. Puerto Rico's registry itself distinguishes the two search fields; the lender's process must preserve how one became the other.[2]
What if the business name and SOS ID point to different records?
Stop the automatic route and surface the disagreement. A different result can come from a suffix variation, DBA, prior application error, a foreign registration, an incorrect ID, or a different entity with a similar name. The article cannot determine which explanation is correct for a live borrower.
The exception record should show the submitted name, the SOS ID, the returned legal name, the source link, and the next decision owner. That gives an underwriter or operations reviewer the facts needed to resolve the case without turning an API response into an unexplained decline.
Why should a no-result or close alternative not end the review?
A no result in a state-scoped search is not proof that the business does not exist. The current Cobalt coverage guide specifically warns that no result can reflect a name variant, state issue, or a recent filing that is not yet indexed, and recommends checking the state and available identifier before drawing a conclusion.[4]
Use a controlled exception path instead:
1. Confirm the input. Check the supplied legal name, punctuation, entity
suffix, and Puerto Rico state value against the application evidence.
1. Inspect alternatives. When the response returns close candidates,
compare the legal title and permitted registry fields under the lender's rule. Do not accept an alternative solely because it looks similar.
1. Check the jurisdiction question. A business operating in Puerto Rico
may be formed elsewhere and registered there as a foreign entity. The formation record may require a separate review.
1. Record the unresolved reason. Distinguish no result, source error,
missing field, and name mismatch. They are not the same operational state.
1. Escalate under policy. Request clarification, use an approved alternate
source, or assign manual review according to the lender's documented rule.
The Department of State describes domestic and foreign entity services as separate registry work. Its corporate guidance also distinguishes corporations' annual reports from LLC annual-fee obligations.[6] That supports a jurisdiction and entity-type check, not an assumption that all Puerto Rico records represent the same filing history.
Which Puerto Rico response fields can support the comparison?
The current internal field matrix permits discussion of title, SOS ID, status, normalized status, entity type, filing date, formation and registration jurisdiction, agent and address detail, officers, documents, screenshot URL, and source URL for Puerto Rico.[5]
Use those fields according to what they can actually show:
• Title and SOS ID support record selection and later retrieval.
• Status and filing date provide public registration context.
• Formation and registration jurisdictions help identify a potential
foreign-registration branch.
• Agent and address fields support a comparison with the application,
not an automatic fraud conclusion.
• Officer fields provide public-record context, not beneficial-ownership
proof.
• Documents, source URL, and screenshot URL can support source retention
where returned and requested.
The matrix is a capability map, not a guarantee about a specific entity. The coverage checklist explains why: a jurisdiction can be covered while a particular field is absent, stale, or not disclosed for the record in question.[4]
Treat an absent field as unknown until your policy and an approved alternate
source establish something else. It is not a negative result by default.
Where does Puerto Rico SOS Search stop in a lender workflow?
An SOS lookup can establish public registry context. It does not settle every control a lending file may require.
• It is not beneficial-ownership verification. FinCEN distinguishes an
ownership interest from a control person. Its CDD requirements apply to enumerated covered financial institutions, so the article does not claim that every alternative lender has the same duty.[7]
• It is not TIN or EIN verification. The Puerto Rico feature evidence does
not establish a tax-identity response in this SOS coverage.
• It is not a UCC, sanctions, or credit check. Those controls need their
own authorized sources and rules.
• It is not a policy engine. The lender decides whether a record, mismatch,
or missing field advances, pauses, or exits the file.
The broader lesson is shared by state filing offices. NASS notes that domestic and foreign registration systems, filing rules, and fees vary by jurisdiction.[8] The correct design is a layered workflow that lets a Puerto Rico state record answer its own narrow question and routes the rest to the appropriate control.
How should this input rule fit into a pre-funding workflow?
The input choice should be one small, visible part of an existing case flow. It should not become a hidden lookup that leaves an underwriter without the record it relied on. Cobalt's published guidance for SOS verification describes the same basic sequence: submit the business-identification inputs, retrieve the state evidence, compare it to the file, and route the result or exception for a lender-owned next action.[4]
What can the first request do?
The initial business-name request can establish whether there is a candidate Puerto Rico registry record to examine. A clean comparison may permit the lender to save the selected entity's SOS ID as part of the case evidence. A conflict should keep the file in review. The point is to create a traceable bridge from the applicant's assertion to the state record, not to hide that bridge inside a matching score.
What can a later SOS-ID request do?
A later SOS-ID request can retrieve the same selected record without asking the user to retype a legal name. This is useful when the workflow has a reason to recheck state evidence before funding or while a reviewer is resolving a separate issue. The later request should retain the prior decision context, because a record that was acceptable at one step does not answer every new question that appears in a subsequent credit review.
What should the exception owner see?
An exception screen needs the applicant's submitted name, the Puerto Rico scope, any ID supplied or retained, the returned record title, the raw status, source evidence, and an explicit reason for the pause. It should also show whether the issue is a name mismatch, unknown field, alternative candidate, source failure, or policy question. That makes the human review specific. It does not ask an underwriter to reconstruct a decision from an unexplained `no match` result.
What does the Puerto Rico API request pattern look like?
Puerto Rico uses Cobalt's existing SOS Search route. The feature documentation supports a business-name or SOS-ID entry point and documents `pr` and `puertoRico` as state values.[1]
# Initial discovery when the file has a business name only
curl --location 'https://apigateway.cobaltintelligence.com/v1/search?searchQuery=Example%20Business&state=pr&liveData=true' \
--header 'x-api-key: YOUR_API_KEY' \
--header 'Accept: application/json'
# Later retrieval after the lender has retained the selected Puerto Rico SOS ID
curl --location 'https://apigateway.cobaltintelligence.com/v1/search?sosId=KNOWN_SOS_ID&state=pr&liveData=true' \
--header 'x-api-key: YOUR_API_KEY' \
--header 'Accept: application/json'The examples show input shape only. They do not represent a live entity, guarantee a response field, or prescribe an approval rule. Before a team uses a field in automation, it should test representative, lawfully accessible Puerto Rico records and verify what its own integration receives. Cobalt's published guidance advises testing coverage at the field level rather than assuming that a state-level availability claim settles every implementation question.[4]
How should an engineering team test this input rule before production?
Use a representative test set and retain the results as implementation evidence. The test should include a clean business-name search, a known-ID recheck, an expected name variant, a foreign-registration branch if relevant, and a case with a field the lender's policy would normally consume.
For each scenario, record the original input, the raw response state, selected record if any, retained SOS ID, source evidence, and resulting exception or advance decision. NIST's log-management guidance frames useful records as data that can be generated, stored, accessed, and analyzed for an operational purpose.[9] The practical application here is straightforward: a later reviewer should be able to see which Puerto Rico record was checked and why the workflow trusted, paused, or escalated it.
The Department of State's corporate forms and service pages show that the registry supports registration, filings, fees, and certifications.[10] Do not infer a certificate or filing outcome from a name search. If a lender's policy requires a certificate or other document, request and verify that evidence under the relevant process.
What should a lender do next?
Define the input rule before the feature enters a funding workflow:
1. Use the business name and Puerto Rico scope to start discovery when the file
lacks an accepted state record.
1. Preserve the selected title, SOS ID, source evidence, and decision reason.
2. Reuse the retained SOS ID only for the same selected state record.
3. Route no results, alternatives, conflicts, missing fields, and source
failures to a named exception process.
1. Keep separate controls for ownership, tax identity, liens, sanctions, and
credit policy.
For the broader boundary around Puerto Rico registry evidence, see Puerto Rico Business Entity Verification: What Alternative Lenders Need to Know. For a field-level vendor-evaluation approach, see SOS API Data Coverage by State: The Buyer's Checklist.
If your team is adding Puerto Rico to its verification workflow, request a coverage test from Cobalt using the exact fields and exception cases your policy needs to handle.
.jpg){kind=small}
.png)