Asking a counterparty to connect a system, not send an export

There are two ways to get a counterparty's financial data: they export it, or they connect the system it lives in.

The export is what usually happens, and it is worse for both sides in ways that are easy to state and rarely stated.

Why a connection is better evidence

It is current. An export is a photograph taken on the day someone was asked. Six weeks later, at committee, it is a photograph of six weeks ago. A connection is the thing itself.

It cannot be assembled selectively. This is the uncomfortable one, and it is the real reason a connection is better evidence rather than merely more convenient. Nobody is suggesting your borrower would omit an awkward account — but the possibility is what makes an export a weaker artefact, and everyone in the room knows it.

It closes several items at once. Aged debtors, bank mandate, revenue by customer and trading history are separate requirements satisfied by the same access, which means one ask rather than four.

It is less work for them. Assembling a year of exports by hand costs somebody an afternoon. Granting read-only access takes two minutes. Deal teams routinely assume a connection is the bigger ask when for the counterparty it is usually the smaller one.

Why they hesitate anyway

Not effort. Scope, and the fear of open-endedness.

The unspoken questions are: what exactly can you see, who at your firm can see it, how long does this last, and what happens to it when we are done? A request that does not answer those in advance invites a no, and the no is reasonable.

How to ask so it gets granted

Four things, all of which should be in the request rather than available on request.

Name the scope in plain words. Not "read-only access" — which data. "The general ledger, the aged debtor and creditor reports, and bank account balances. Not payroll, not customer contact details."

Name the purpose. Tie it to the items it satisfies, by number. A grant that exists to close items 4, 11 and 12 is a different proposition from a grant that exists because you asked for one.

Name the expiry, and make it real. "Until close, or 90 days, whichever is sooner." Access that expires because somebody remembers to revoke it is not an expiry. It should end on its own.

Name the revocation. Say plainly that they can withdraw it at any moment, from their own system, without asking you — and that doing so will not stall the deal, because you will fall back to exports for whatever is left.

That last one is the clause that changes the answer most often, and it costs nothing.

After it is granted

Two disciplines that determine whether the next counterparty says yes.

Scope it to the deal, not to the workspace. A grant made for one facility should not be reachable from another deal file, and should not survive the deal it was made for. This is a technical property, not a policy: if the access is workspace-wide, then no amount of internal care makes the promise you made true.

Revoke it when you close. Including on deals you pass on — especially on deals you pass on. A borrower who declines your terms and then notices you still have live access to their ledger three months later will tell people, and they will be right to.

What not to do

Do not ask for write access. There is never a diligence reason for it, and asking once tells the counterparty you have not thought carefully about what you are asking for, which colours everything else you ask for afterwards.

Do not use it for anything but the deal. Not for market research, not for a benchmark, not for a model. The access was granted for a purpose you named, and using it for a second purpose is the kind of thing that ends a relationship and occasionally a firm.

Do not treat a refusal as an obstacle to work around. Take the export, note that a connection was declined, and carry on. It is information about how they run things, and it goes in the file like anything else.