The catalogue
The set of sources is closed and declared in the Platform’s own code. A source that is not declared cannot be reached, and a declaration states five things before the Platform will start with it.
The four postures, and what each records:
Two sources failing under opposite postures settle to
refuse. It is not a tie broken by ordering. It is the stricter of two standing instructions.
The posture is recorded on the decision, not looked up when one is read, so changing a source’s posture never changes what a past decision replays to.
The Platform’s own loan book is a source. It is reached in process, needs no credentials and no authorisation: nobody authorises the Platform to read what it recorded itself, and answers what your repayment history with a client actually is rather than what somebody declared it to be.
A network source declares two more things the catalogue read serves you: which identity fields admit an alternative (identity_any_of, meaning “RFC or CURP”), and its failure vocabulary, the closed set of outcome names its attempts record, each marked retryable or not, so your handling is written against the declared set rather than reverse-engineered from an outage.
Círculo de Crédito
The first network source: the credential document, the identity fields, the consulta, the folio, and what its failure means.
Enabling a source
Nothing is enabled by default. Enabling is a recorded act performed by a named person at the Console, and it states how many lookups a day that source may make on your behalf. Withdrawing a credential binds at once: the next lookup is refused. Work already in flight completes, because a lookup that has left is one your account is billed for whatever happens next. Rotating is the other order. Supply the new credential first, then withdraw the old one, because supplying does not withdraw what is there, so there is no window in which you cannot look anything up.Lookups
A dispatch to a source that reads a borrower’s file carries four things about authorisation, and the Platform checks all four before anything is fetched.
A missing, expired or unattested authorisation refuses the dispatch naming which, and no call leaves. That timing is the point: at a Mexican bureau, a lookup registers an enquiry on the borrower’s file for twenty-four months, so checking afterwards would mean the enquiry had already happened before the Platform noticed nobody was authorised.
Refusals
Everything the Platform can answer from what it already holds is answered before a call leaves.
These are the source surface’s own codes. On
POST /credit-decisions, the one route that dispatches. Most of the platform-side refusals above arrive as 422 under the single code source_access, carrying the same sentence inside it, so one branch of your integration handles all of them.
Two do not, because the remedy is not the same one.
The ledger
GET /v1/tenants/{tenant_id}/source-ledger answers every lookup made on your behalf: when, which source, about which client, under which application, under which authorisation, what came of it, the source’s own reference where it assigned one, and what it cost.
It carries no payloads. Not the request, not the response, not the report. It is evidence that a lookup happened and under what authority, which is the duty it serves, and never a second copy of a person’s credit file.
Narrow it to one client with client_id, which is the shape the question actually arrives in: a person asks their lender what was looked up about them.
Custody
Two things come back from a lookup that the Platform holds: the identifying fields it was addressed by, and the source’s raw response. Both live beside the decision they served, never inside it. That split is what makes two promises true at once. A decision is never edited and never deleted. It is what the Platform can be asked to reproduce years later. What was held about the person can be destroyed whole, and destroying it leaves the decision reading exactly as it did: every derived attribute, the trace, the outcome, the source’s own reference. The Platform’s position, in full:- Identity and reports are held while you remain a client.
- At offboarding you elect return or destruction. A return hands you the files whole and then the Platform stops holding them: a return that left a copy here would be custody that did not end.
- Absent an election within 90 days, the Platform destroys.
- Every destroyed file leaves one ledger entry naming the client whose file it was and the day it went, so “was mine among them” is answerable without a join nobody kept.
- The decision records and the ledger entries recording each lookup are untouched by any of this.
Requests from the data subjects themselves, a borrower asking what is held about them, or asking for it to be corrected or removed, route to you, not to the Platform. You hold the relationship, you captured the authorisation, and you are who they contracted with. The Platform answers you.