← Back

Blog

Let an agent act for your customer without holding their access

The service you cannot launch is the one that acts on someone's behalf. It stalls because doing the work means holding their credential. It does not have to: the value can stay on their phone and never reach you at all.

Manah Khalil/

The proposition is easy to describe and hard to ship. Your customer wants the work done for them, the reconciliation, the claim, the transfer, and doing it means acting somewhere they have access and you do not. So you ask them for the credential, and the moment you do, three things become yours: their password, the liability for it, and a conversation with your own risk function that you will not win.

Most teams solve this by not solving it. The customer does the last step themselves, and the service is worth less than it should be.

The offer without the custody

A person's own credential can stay on that person's phone. When the work reaches the step that needs it, the phone makes that one call itself and only the result comes back. You never receive the value, and neither does your gateway. What you get is the outcome you were going to ask them to produce by hand.

Where the credential is the company's rather than the person's, it works the other way round and stays on your side: it is read for one call and discarded, and it never goes near anybody's device. Both are the same product, chosen per call by policy.

Whose secret decides who dials
Asking the customer for their credential
Customer
Your service holds it
Their bank
Their access, your custody. This is the version that does not get approved.
Delegated execution
Your service stand-in
Gateway
Customer's phone
Their bank
The green box is the only place the credential exists. The result returns along the same path; the value never does.
Your service is the first box in both, and receives the outcome in both.
Fig 01The same errand, run two ways.

What it changes for the service you sell

  • The last step comes back in scope. Work you handed back to the customer to finish can be finished for them.
  • You are not asking for a password. Which is the sentence that ends most of these conversations, on both sides of the table.
  • Consent is per action and legible. The customer sees the actual action and agrees to that one, rather than granting standing access and hoping.
  • A breach of your service exposes none of it. There is no store of customer credentials to lose, because you never built one.
How this is offered elsewhere How Squidder does it
Ask the customer for their credential Never ask for it; it stays on their phone
Standing access, granted once Access for one action, then gone
Consent to terms, in the abstract Consent to the action, as it is about to happen
Hand the work back for the customer to finish Finish it, with their agreement on record
A store of customer credentials to defend No store, so nothing to defend

Where it fits, and where it does not

This needs a person with a phone at the far end, which is why it suits servicing and advisory work rather than an overnight batch. Where nobody is behind the call, the company path serves it without inventing somebody to ask. And a credential the customer types into a browser themselves is outside this entirely.

Where to start

Find the step in your best service where you currently stop and ask the customer to do it. That step is the pilot.

The five ways a value can reach a call, and why the company path never touches a phone, are in Take the credential out of the application entirely.