Account-holder locks
Account-holder locks
The account owner can, in internet banking, block outgoing payments, limit the hours and restrict source IPs. Those rules apply to your API the same way they apply to the UI. You read what is in force; the holder is who tightens or loosens the lock.
What the API returns when a lock blocks a payment
That is not a signing failure. Tell the holder or wait for the window.
The credential IP allowlist (ip_not_allowed at the edge) is a
different list — see Keys and IPs.
Read the locks
GET /v1/accounts/{accountId}/security/locks (read scope):
If the holder asked for a loosening (unblock, widen the window, add an
IP), the change waits 6 hours and appears in pending +
pendingEffectiveAt. Until then the stricter current applies.
There is no PUT on these routes for this credential. Trying returns 403.
Per-operator limits
The holder slices the account ceiling at
GET|PUT|DELETE /v1/accounts/{accountId}/limits/operators/{document}.
Tightening is immediate; raising or removing waits 6 hours. On cashout,
available = min(account, operator). PIX reserves locally when an
operator ceiling or a staff-written account ceiling exists. The
partner still enforces the account PIX ceiling; GET .../pix/limits
does not change.
GET /v1/accounts/{accountId}/limits/available is the unified read
(used/remaining). GET .../pix/limits does not change: partner ceilings
only, no used field.
Operator PIN
The PIN exists for the bank UI (the holder’s credential). Your
credential does not send X-Transaction-Pin. Routes that set, verify or
reset a PIN (/security/pin) return 403 for this audience.
Who else operates the same account
GET /v1/accounts/{accountId}/shared-access lists other access to the
same bank account: display name, state and since when. No credentials,
balance or configuration of the others — only what the holder already
sees in internet banking.