The checks no third party can run for you
Some of the most decision-relevant signals in trade finance sit behind credentials that belong to the lender, not to any vendor. Account Aggregator(AA) cashflow runs on the lender’s own FIU registration; a CERSAIcharge search runs on the lender’s membership and DSC; CKYC and GeM/PFMS are the same. These are not data a technology provider can — or should — hold. So the only compliant way to use them is lender-side: inside the lender’s trust boundary, under the lender’s identity.
What AA cashflow actually tells a lender
With the borrower’s consent, the lender’s FIU pulls bank-statement data through the RBI Account Aggregator framework. The consent artefact itself is granular — it names the purpose, the FI types, the fetch frequency and an expiry — and it is granted to the lender as FIU, not to any intermediary. From the returned statements the lender computes aggregates— average monthly balance, an inflow trend, an income estimate, a balance band, bounce and overdraft frequency — that corroborate the borrower’s capacity to fulfil the order and service the facility. Combined with a CERSAI search, AA is also where duplicate-financing risk surfaces: is this receivable already pledged, does an existing charge sit against the same asset, and does the cashflow square with the story the borrower is telling?
None of this can be delegated to a vendor. The FIU registration, the AA consent, the CERSAI membership and DSC — each is issued to a regulated entity and is non-transferable. A technology provider that offered to “run your AA pull” would either be sharing the lender’s credentials (a compliance breach) or acting outside the consent the borrower actually gave. The lawful shape is the opposite: the privileged call stays where the credential lives.
Aggregates, not raw data
A clean posture keeps the raw financial data inside the boundary that pulled it. The principle is minimum-retention: the lender’s FIU computes the aggregates and derived metrics, and the raw FI payload is discarded— only the bands and tier travel onward as a signal. That is consistent with both the RBI AA framework’s intent and DPDP’s data-minimisation and purpose-limitation expectations, and it means the signal can be used downstream without raw bank statements ever leaving the lender. Discarding the payload also shrinks the breach surface: there is no warehouse of borrower statements to leak, and no second copy sitting with a vendor.
The same logic sorts every privileged check into one of two buckets. Some run on credentials that belong only to the lender and therefore stay lender-side; others rest on the borrower’s own consent to public or semi-public records and can be run shared — by the lender or, with that consent, by a technology provider. Knowing which is which is the whole compliance question:
| Check | Source | Lender-side or shared | What it yields |
|---|---|---|---|
| AA cashflow | RBI Account Aggregator, on the lender’s FIU registration | Lender-side | Balance band, inflow trend, income estimate, bounce frequency |
| CERSAI charge search | CERSAI, on the lender’s membership + DSC | Lender-side | Existing-charge / duplicate-financing flag against the asset |
| CKYC record | CKYCRR, on the lender’s reporting-entity access | Lender-side | Match against the central KYC record |
| GeM / PFMS lookup | Government marketplace / disbursement rails, on the lender’s access | Lender-side | Order / payment-flow corroboration for the deal |
| GST & e-invoice authenticity | GSTN / IRP, on borrower consent | Shared | Filing regularity, invoice / goods-movement authenticity |
| Identity at source | DigiKYC / DigiKYB, on borrower consent | Shared | Verified identity of the borrower and its signatories |
The AssureConnect pattern
AssureLocker runs these as AssureConnectconnectors: the privileged call executes inside the lender’s own environment, on the lender’s credentials, over mutually-authenticated TLS, and returns a binary or banded signalplus a provenance hash — never raw records. AssureLocker holds no AA, CERSAI or CKYC credentials and never calls those registries directly. The request is signed, the response is verified, and the signal’s provenance is recorded — so the lender gets the answer with an auditable trail and no credential-sharing.
Toward a shared first-financing view — without central credential-holding
The single check most lenders wish they could run is “has anyone else already financed this receivable?” CERSAI answers part of it, but duplicate-financing risk is a network problem: it is best seen when many lenders can compare notes on what has been pledged. That is what AssureFirst is being built toward — a shared first-financing / lender-side-checks layer where participating lenders can surface an existing-charge or already-financed flag against a receivable.
It is honest to be precise about the stage: AssureFirst is forming with design partners, not a live universal registry, and even as it matures each participating lender verifies independently— the shared view is corroboration, never a substitute for the lender’s own CERSAI and AA checks on its own credentials. The design goal is a network signal that raises a flag; the confirming pull still happens lender-side.
Why it matters for the decision
These lender-side checks are often the difference between a confident yes and a decline: they catch the already-financed receivable, the cashflow that doesn’t support the order, the charge that shouldn’t be there. Surfacing them — compliantly, as a signal labelled by tier — is what lets a lender extend into cases they’d otherwise avoid.
The frame throughout is the same, and it is a deliberate one: signals, not decisions. AssureLocker computes signals within the lender’s permitted boundary — through AssureConnect connectors and, as it forms, the AssureFirstshared view. It does not hold the lender’s AA, CERSAI or CKYC credentials, does not call those registries on the lender’s behalf, and does not lend, decide or guarantee. The lender owns the call, the customer relationship, and the credentials; AssureLocker just makes the privileged check usable at the point of credit.