The credit registry reads the official report, and the labor check names its holder

Credit registry: the whole report, read from the Bank of Spain’s document

The credit registry is now filled from the official CIRBE report itself: every operation the holder has with each institution, the minor risks, and the totals, exactly as the Bank of Spain printed them. The report still travels as an attachment, and its metadata now carries the verdict on its digital signature — who signed it and whether the signature is valid.

If you integrated against the sandbox, the operation keys changed shape. Each key the report prints — product type, intervention, joint liability, residual maturity, guarantees, situation — now arrives as its meaning (financial_credit, direct_holder…), and the code exactly as printed travels beside it in a field of its own, named after the key with _code (product_type_code: "V32"). Read the meaning; keep the code for display or audit.

Two more things to know:

Every amount is always present. One the report does not give reads as unknown — currency ***, amount NaN — as on every other money field of the platform, never as zero.
The holder is reported only when the report could be read. A report that could not be interpreted still arrives attached, with the product saying what is missing.

Labor check: who the reports are about, and a longer history

The labor check carries two new fields, holder_name and identifier (the DNI or NIE), exactly as the official Social Security reports print them. They record what the documents say; comparing them with your customer’s identity is your decision. When the two reports name the same person differently, holder_name is not reported and the product is worth a careful review — the data model page explains what to look at.

The contribution history now covers five years by default and up to eighty, through the feature’s from_date — see Features. A date outside that range is adapted, never refused: further back than eighty years reads eighty, and less than a year back reads one year. When the official reports cannot be used and the history is read from the Social Security’s pages instead, it covers the last twelve months.

Direct Executions: tokenizing without the capability answers `403`

Asking for base_configurations.tokenized_access from an application that is not allowed to tokenize now answers 403 with detail: insufficient_capabilities@login:tokenized_access, on both launch endpoints, instead of the 400 that carried status_reason: T10N_FORBIDDEN. Branch on the part before the @, which never changes; what follows names the capability you are missing. A sandbox run is never refused for a capability. Credential Tokenization explains how to have it enabled for an application.