CBA Business Banking Payment Initiation

payment_initiation

Authority to instruct one payment out of the delegating customer's business transaction account. The instructedAmount is the ceiling for this token, the root_budget claim is the ceiling for the whole delegation, and the single payment limit published in the policies below applies on top of both.

Required members: type purpose instructedAmount

Optional members: for invoice payee dual_authorisation constraints

{
  "type": "payment_initiation",
  "purpose": "Accounts payable settlement for approved supplier invoices",
  "instructedAmount": {
    "amount": "8200.00",
    "currency": "AUD"
  },
  "for": "supplier_invoice",
  "invoice": "INV-1041",
  "payee": {
    "name": "Ellerman Freight Pty Ltd",
    "bsb": "062-000",
    "account": "10029481"
  }
}

Every call carries a token from the named authorization server

Calls are accepted only with an access token issued by https://netbank.demo.cba.raidiam.io and addressed to this resource as its audience. A token minted for a different resource is refused even when it is otherwise valid.

Refusal reason missing_access_token, invalid_token · decided at authorization · policy id rs.authenticated_caller

What clears it: Read this metadata document, then request a token from the authorization server it names, with this resource as the audience.

Authority is the RFC 9396 detail type, not a scope

Each tool names one authorization_details type. The token must carry that type, or an umbrella type that narrows to it. Holding a scope, or holding authority for a neighbouring resource, does not admit the call.

Refusal reason insufficient_authority · decided at authorization · policy id rs.authority_gate

What clears it: Obtain a token carrying the detail type the tool names. Delegation only ever narrows, so the delegating envelope must already contain it.

A revoked delegation stops working before its tokens expire

Revocation arrives as a Shared Signals event and is applied to the delegation, not to a single token. Every token issued under a revoked delegation is refused from that moment, whatever its expiry says.

Refusal reason delegation_revoked · decided at authorization · policy id rs.revocation_honoured

What clears it: The customer must grant a fresh delegation. There is no way to appeal a revocation at the resource.

Sender constrained tokens are bound to the key that holds them

A DPoP proof is verified whenever one is presented, and is required whenever the access token names a key in its cnf.jkt claim. Each proof is accepted once, so a captured proof cannot be replayed.

Refusal reason dpop_proof_required, invalid_dpop_proof, dpop_key_mismatch, dpop_proof_replayed, access_token_not_dpop_bound · decided at authorization · policy id rs.dpop_binding

What clears it: Request the access token with a DPoP proof so the authorization server binds it to your key, then send a fresh proof with every call.

A malformed request is refused with the reason it was malformed

Arguments are validated before any business rule runs, and the refusal names the argument at fault rather than returning a bare failure.

Refusal reason tool_error, invalid_amount, unknown_tool · decided at execution · policy id rs.request_validity

What clears it: Correct the named argument. The tool schemas are published in this document.

Every payment is counted against a delegation

A payment is made only when it can be counted. The token must carry a root_grant claim identifying the delegation the customer approved, and spend is accumulated against that id across every sub agent acting under it.

Refusal reason envelope_not_identified · decided at execution · policy id pay.envelope_required

What clears it: Obtain the token through the delegation chain that begins with the customer approval, so it carries the root_grant of that delegation.

A payment never exceeds the amount its own token names

The instructedAmount on the payment_initiation detail is the ceiling for that token. A sub agent attenuated to one invoice cannot spend beyond the amount it was attenuated to.

Refusal reason token_authority_exceeded · decided at execution · policy id pay.token_authority

What clears it: Pay no more than the amount the token names, or obtain a token issued for the larger amount from within the same envelope.

No single agent initiated payment above AUD 20,000.00

The bank applies its own ceiling of AUD 20,000.00 to any one payment initiated by an agent. It is independent of what the customer delegated, so an agent cannot get past it by asking for a larger token. Clearing it takes a second human approver, and the approval is carried back as a dual_authorisation claim.

Refusal reason single_payment_limit_exceeded · decided at execution · policy id pay.single_payment_limit

What clears it: Take the payment to a second approver over CIBA and present the token that approval produces.

Cumulative spend never exceeds the approved envelope

Every settled payment under a delegation is added up, and any leg that would take the total past the customer approved envelope is refused. When the token names no envelope this resource applies a default of AUD 50,000.00 rather than treating the delegation as unbounded. A second approver clears the single payment limit but does not raise the envelope.

Refusal reason envelope_budget_exceeded · decided at execution · policy id pay.cumulative_envelope

What clears it: The customer must approve a larger envelope. No approval inside the agent fan out can create headroom that the customer did not grant.

An invoice is settled once per delegation

Sub agents run in parallel and can be handed overlapping work. An invoice already settled under this delegation is refused a second time, and the refusal names the original settlement.

Refusal reason invoice_already_settled · decided at execution · policy id pay.no_duplicate_settlement

What clears it: None. The invoice is paid. A wrong payment is reversed through the bank, not corrected by paying again.

The payment settles what the grant said it would settle

When the payment_initiation detail names what it is for, the instruction must name the same thing. A token issued to settle one invoice cannot be redirected to another.

Refusal reason purpose_mismatch · decided at execution · policy id pay.purpose_consistency

What clears it: Instruct the payment the token was issued for, or obtain a token for the other one.