Product guide · KYB
A primary Spanish KYB provider verifies identity. BORMEAPI shows what changed around it.
A primary KYB provider answers the identity question: does this NIF belong to a legal entity, and what does the authoritative source say about it? Keep that provider. BORMEAPI solves the next problem: what has been published about the company since it was verified, and what should trigger another review?
Appointments, terminations, capital operations, address changes, dissolutions and insolvency notices appear as dated entries in Section A of BORME. The source is public. Turning years of those entries into an ordered, searchable history — and operating that ingest after each BOE publication — is the paid layer.
The expensive mistake is a confident identity guess
Ordinary BORME entries usually identify a company by legal name and registry coordinates, not by NIF. BORMEAPI supplements that publication history with NIF mappings from other sources, where available, and exposes the source and confidence of each mapping.
That means an integration needs more than found and not found:
- Matched: one sourced identifier resolves to one compatible company.
- Ambiguous: the evidence points to several candidates.
- Unmapped: the identifier passes format validation, but no supported mapping is available.
- Invalid: the input fails validation.
An unmapped NIF does not prove that a company is absent. A registry sheet can also be shared by several records. A name search produces candidates, not identity. BORMEAPI preserves those distinctions so a workflow can request another identifier or send the case to review instead of accepting the first plausible row.
What the maintained history adds
Once the entity is resolved, the Hosted API returns a company view derived from the ordered BORME-A events processed for that company. It can include current name, officers, capital, address, status and insolvency state, with the underlying publication references retained.
The distinction matters: a derived officer state is useful for screening, but the dated appointment or termination is the evidence. For a decision with legal consequences, follow the source reference and verify it against the official publication or the Registro Mercantil.
Pro also supports an as_of date. That reconstructs the state implied by BORME
publications dated on or before the selected day; it does not prove which API
response a team actually received then. To audit an earlier decision, preserve
the response, retrieval time and publication references at decision time.
Monitoring closes the gap after onboarding
An onboarding check is a snapshot; company risk keeps moving. The maintained ingest can turn later BORME-A entries into signed webhook deliveries and watchlist alerts. A customer does not need to poll BOE files, reconcile format changes or decide whether two notices belong to the same company.
A practical workflow is:
- verify identity with the primary KYB source;
- resolve the company through a sourced NIF mapping or compatible registry coordinates;
- store the BORMEAPI company slug, mapping provenance and publication IDs used in the decision;
- subscribe the resolved company to the change categories that should reopen review.
Store ambiguity as ambiguity. Also store the retrieval time and publication references behind every fact that affected a decision. That evidence is more valuable six months later than a copied status label with no origin.
Why pay instead of reading BORME directly?
The customer is not paying for permission to see a public notice. The customer is paying to avoid maintaining the system between that notice and a reliable workflow:
- daily acquisition and replay of BORME-A publications;
- parsing and normalisation across historical format changes;
- stable event types and company identifiers;
- conservative NIF and registry-coordinate resolution with explicit ambiguity;
- derived current and point-in-time state with source references;
- indexed queries, access controls, watchlists and signed delivery.
That is why BORMEAPI complements rather than replaces primary KYB. The primary source establishes identity. BORMEAPI supplies the sourced history and change stream that make the relationship monitorable.
Try recent events with a free API key See the KYB integration boundary