One Business, Two Platform Customers: Keep Verification Evidence Separate by Tenant and Application

Executive Summary: The same registry business can appear in applications belonging to different platform customers. Its public identifier does not authorize access to either customer's private evidence. Cobalt supplies registry and search identifiers, while your platform must enforce its own tenant and application boundaries.^[1][2]

Which identities need to remain distinct?

Separate the registry entity, platform customer, financing application and source-verification attempt. They may be related, but they are not interchangeable keys.

For example, two lending customers using the same platform may each receive an application from the same business. The state registration can refer to one public entity while the applications contain different requested amounts, documents, reviewer notes and decisions. This is a hypothetical workflow, not an observed Cobalt customer case.

What does the registry identifier establish?

Cobalt's Secretary of State API supports searching by sosId with a state.^[3] That identifies the source record relevant to a lookup. Preserve the jurisdiction with the identifier instead of assuming an identifier string alone is globally unique.

The registry reference can help associate evidence with the intended business. It does not identify which platform customer may view an application or reuse another customer's private review.

What does the source-search identifier establish?

Cobalt's Full Verification flow returns a searchGuid to track a submitted search and retrieve results.^[4] It is a source-request reference, not a tenant permission or an application approval.

Bind it to the internal attempt that initiated the search. The attempt should already know the authorized customer context, application and input revision before the external response arrives.

How should the data model connect those records?

Use explicit relationships rather than treating the business name as a universal join. An application belongs to an authorized customer context. A verification attempt belongs to an application revision. A source observation belongs to the attempt that requested it.

A separate registry reference may identify the public entity associated with that observation. Keep that association distinct from access to the observation itself.

A practical record map includes:

• API-key scope. The documented fullStatusCheckList returns searches associated with an API key, so do not treat it as a tenant-specific authorization filter.^[5]

• Tenant identity. The platform customer whose authorized workflow owns the application.

• Application identity. The particular financing request or business review within that tenant.

• Input revision. The submitted facts evaluated by the verification attempt.

• Provider attempt. The external search reference and supported correlation information.

• Source entity. The relevant jurisdiction and registry identifier where established.

• Private disposition. The customer's reviewer notes, exceptions and lending decision, separately authorized.

Why not join private evidence through the registry table?

Because the registry entity can be shared while the application is private. A query that begins with a public entity and returns every related application can expose another customer's records unless tenant access is enforced at the private-resource boundary.

AWS's current authorization guidance distinguishes identifying a user from deciding which resources that user may access, and it treats tenant isolation as a separate requirement.^[6] A successful login does not make every application about the same business visible to that user.

What if one customer has multiple applications?

Keep application identity in the relationship as well. The same tenant can have separate applications with different input versions, evidence ages and decisions. Tenant equality alone should not decide which result supports which financing request.

What should an authorized evidence query require?

Start from trusted server-side identity and the access policy for the requested resource. Do not accept a client-supplied tenant value as proof that the caller belongs to that customer context.

The following SQL illustrates a scoped lookup with bound parameters supplied by an authorized application layer. It is a design example, not a complete access-control implementation.

SELECT observation_id, provider_request_id, source_reference
FROM verification_observations
WHERE tenant_id = :trusted_tenant_id
  AND application_id = :authorized_application_id
  AND input_revision = :requested_revision;

What does this example leave to the application?

The application must establish the trusted tenant, authorize the requested application and determine whether the user may access that revision and evidence type. The query does not create those permissions by itself.

Apply equivalent controls to exports, attachments, callbacks, background jobs and support views. A protected main API route does not resolve a separate unscoped download or report query.

Does shared infrastructure change the requirement?

No. AWS's SaaS Lens describes applying tenant scope when shared functions access resources, including designs that obtain tenant-scoped credentials at runtime.^[7] The specific mechanism depends on the platform, but the customer boundary still needs explicit enforcement.

This article does not claim that using Cobalt establishes a security certification or supplies the platform's native tenant-isolation controls. Cobalt's documented role here is source-data retrieval and request identification.

How should asynchronous results find the correct application?

Create the internal verification attempt before calling the provider, then bind the returned source identifier to that attempt. When an event arrives, resolve it through the retained mapping rather than searching current applications by business name.

Cobalt's Full Verification documentation supports a callback route and status checks using the returned search reference.^[8] Both delivery routes should reach the same authorized attempt record.

What if two tenants submit the same name?

Their internal attempts remain separate. A response for one attempt should not populate the other's private application merely because the submitted name matches. Preserve the provider request reference and the originating customer context.

If your contract and design allow reuse of some source data, make that a separate controlled operation with its own evidence-age and input checks. Do not obtain reuse by accidentally joining private records through a shared company name.

What if the application changes before the result arrives?

Keep the input revision in the mapping. A result can belong to the correct tenant and application while still evaluating superseded inputs. Preserve the observation and decide whether it can support the current review through an explicit rule.

The no-match exception operations guide provides broader context for resolving the evidence question. Access control and application correlation should be established before that review begins.

Can public-source data be reused across customers?

Only through a design that establishes permitted use, appropriate evidence scope and the separation of private information. Verify the relevant contractual and access requirements before implementing shared reuse. Public origin does not make every record assembled around that data public.

Distinguish the registry fact from the private request that retrieved it, the applicant's supplied information and the customer's interpretation. Even when a source fact is reusable, another customer's search history or lending decision may not be.

What should a shared source record exclude?

Exclude private application fields, customer-specific reviewer comments, document attachments and dispositions unless the specific sharing is authorized. Keep the original source provenance and observation context accurate.

Do not construct a global “approved business” record from one tenant's decision. Approval describes a customer decision under its own policy and application facts, not a permanent property of the registry entity.

How should reuse be evaluated?

Check the intended entity, relevant inputs, source observation date, permitted purpose and current evidence requirement. Record why the reused source information is suitable for the receiving application without disclosing another customer's private context.

Cobalt's SOS API distinguishes source status and normalized status, while Full Verification separately tracks a submitted search.^[9] Neither distinction turns a previous customer's approval into reusable source data.

A shared business identity can connect public facts without connecting private lending decisions.

What does a two-customer test case look like?

Create synthetic tenants A and B, each with an application concerning the same registry entity. Give their applications different input revisions and private reviewer notes. Initiate separate verification attempts and deliver their responses in reversed order.

The expected result is that each observation reaches its own attempt and authorized application. A user from tenant A should not receive tenant B's private evidence through an application view, search result, export or document link.

What should the test try besides the normal interface?

Test direct application identifiers, source-search identifiers, registry searches, attachment references and exported reports. An access denial in one screen does not prove that the same resource cannot be obtained through another route.

Use the actual authorization rules and trusted identity context of your platform. AWS's current guidance calls for API access controls that verify the caller's access and preserve tenant boundaries.^[10]

What should happen if an event cannot be correlated?

Keep it in a restricted unresolved state for investigation. Do not assign it to the first tenant with a similar business name or recreate an application based on a partial match.

Record enough permitted request context to investigate the issue without exposing one customer's data to another. The unresolved event is an integration task, not evidence that a borrower failed verification.

How should support and operations inspect the records?

Give support the scoped tools needed for an authorized investigation. A broad search across tenants should not be the routine workaround for missing application relationships. Where elevated access is permitted, its purpose and use should be traceable under the organization's policy.

The reviewer-facing history should identify the source observation, input revision and customer disposition without requiring staff to understand the database design.

What if the provider returns prior searches in a listing?

Apply the platform's own authorization before exposing any item to a customer. Cobalt's fullStatusCheck documentation describes viewing previous and potentially ongoing requests associated with the API key.^[11] If that key serves multiple platform customers, the provider listing is not automatically a tenant-scoped customer response.

This is a concrete boundary to test. The backend must correlate and filter evidence according to authorized internal relationships before returning it to the caller.

What should a handoff note say?

Identify the permitted application reference, source attempt, unresolved correlation or access issue and next owner. Avoid copying an entire cross-customer listing into a general ticket when a scoped reference is enough.

The multi-tenant screening integration guide provides related platform context. The same principle applies to business-verification evidence: a valid source identifier does not replace the customer's access boundary.

How should you test updates and reuse over time?

Add cases where one tenant corrects the business name, another starts a renewal and a shared source record receives a newer observation. Confirm that the update does not alter the other tenant's private application or retrospectively change its completed review.

What should remain historical?

Preserve the source evidence and policy disposition that supported each decision. A newer registry record may be relevant to a later review without making an earlier review's evidence disappear.

Middesk's monitoring timeline documents changes to business attributes over time.^[12] That illustrates the value of retaining observations, while your platform still determines which customer and application may access each private record.

Which operating measures are useful?

Measure unresolved correlation events, denied cross-tenant requests, incorrect application associations found in testing and evidence-reuse decisions requiring manual review. Use your own observations rather than claiming that a particular identifier design eliminates every risk.

Review export and attachment paths when the application adds new features. A new data surface needs the same tenant and application checks as the existing evidence view.

What should a Cobalt evaluation demonstrate?

Bring a synthetic two-customer scenario and the source-request mapping you intend to use. Ask to inspect returned identifiers, status listings, callback correlation and the exact business-record fields relevant to your application.

Cobalt's documented Full Verification flow provides source results for a later review; it does not define the customer's tenant-authorization model.^[13] Keep that boundary explicit in the integration design and acceptance tests.

Schedule a Cobalt demo with the scenario. The practical goal is to connect each source observation to the right business and the right authorized application, while keeping another customer's private evidence and decisions outside that relationship.