From consent to mandate: why a login is not authority to pay
Authenticating a customer proves who they are, not what an agent may do for them. A mandate states the action, amount, payee and time window, and travels with the request.
When an agent acts for a customer, the tempting shortcut is to reuse what already exists: the customer logs in, the agent inherits the session, and whatever the customer could do, the agent can do. That merges two different things. Authentication establishes who the customer is. Authority says what may be done on their behalf, how much, with whom and until when.
Payment law already draws this line. Under PSD2, a payment is authorised only if the payer has consented to it in the form agreed with their provider. In the United States, the CFPB's personal financial data rights rule requires a third party to obtain the consumer's express informed consent before accessing data, and limits use to what the requested product needs.
A mandate makes authority explicit. It names:
- the action, such as paying one supplier invoice or buying groceries;
- the limits, such as a maximum amount, a currency and a merchant;
- the time window, and how the customer can revoke it.
The mandate can travel in several forms. OAuth Rich Authorization Requests put structured payment details into the token. The Agent Payments Protocol expresses mandates as signed digital credentials. Either way, the party executing the action can check the request against the mandate without taking the agent's word for it.
Practical starting points:
- Never let an agent reuse a customer's full session or credentials.
- Store the mandate with every action taken under it.
- Keep data consent and payment authority as separate grants.
Sources: Directive (EU) 2015/2366, PSD2 (EUR-Lex, archived), CFPB: Personal Financial Data Rights rule, RFC 9396: OAuth 2.0 Rich Authorization Requests, Agent Payments Protocol (AP2) documentation