{"resource":"https://rs-payments.demo.cba.raidiam.io","resource_name":"CBA Business Banking Payment Initiation","resource_documentation":"https://rs-payments.demo.cba.raidiam.io/","authorization_servers":["https://commbiz.demo.cba.raidiam.io"],"bearer_methods_supported":["header"],"scopes_supported":["openid","payments.initiate"],"authorization_details_types_supported":["payment_initiation"],"dpop_signing_alg_values_supported":["ES256"],"dpop_bound_access_tokens_required":false,"tls_client_certificate_bound_access_tokens":false,"cba_resource_profile":{"profile_version":"1.0","treatment":"CBA side illustration, not a Raidiam product","operator":"Commonwealth Bank business banking, illustrative reference model","domain":"accounts payable","summary":"Instructs supplier payments out of a business transaction account under a delegated envelope, enforcing the cumulative envelope across every sub agent and a single payment limit on each one.","read_only":false,"dpop_binding":{"mode":"bound","description":"This resource verifies a DPoP proof whenever one is presented, and requires one whenever the access token carries a cnf.jkt claim. Plain bearer tokens are still accepted while the authorization server is being moved onto sender constrained tokens."},"trust":{"authorization_server":"https://commbiz.demo.cba.raidiam.io","trust_anchor":null,"federation_required":false,"description":"No federation trust anchor is configured, so the authorization server named above is trusted by configuration alone. Set RS_TRUST_ANCHOR to require a resolvable trust chain."},"authorization_details_profiles":[{"type":"payment_initiation","title":"Payment initiation","description":"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.","actions":["initiate"],"required_members":["type","purpose","instructedAmount"],"optional_members":["for","invoice","payee","dual_authorisation","constraints"],"example":{"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"}}}],"required_token_claims":[{"claim":"sub","required":true,"description":"The business banking customer who approved the delegation."},{"claim":"root_grant","required":true,"description":"The stable id of the root delegation. Spend is accumulated against it across every sub agent, so it must survive every attenuation hop unchanged."},{"claim":"root_budget","required":false,"description":"The envelope the customer approved, as an amount and currency. When absent this resource applies its own default of AUD 50,000.00 rather than treating the delegation as unbounded."},{"claim":"act","required":false,"description":"The RFC 8693 actor chain. Recorded on every decision so a settled or refused payment can be traced back to the sub agent that asked for it."},{"claim":"dual_authorisation","required":false,"description":"Evidence of a second human approver, carrying approved_by and auth_req_id. Required for any single payment above AUD 20,000.00."},{"claim":"cnf.jkt","required":false,"description":"The thumbprint of the key the access token is bound to. A DPoP proof signed by that key must accompany every call that presents it."},{"claim":"authorization_details[payment_initiation].instructedAmount","required":true,"description":"The ceiling for this token. A payment above it is refused whatever envelope is left."}],"policies":[{"id":"rs.authenticated_caller","title":"Every call carries a token from the named authorization server","statement":"Calls are accepted only with an access token issued by https://commbiz.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.","denial_reason":"missing_access_token, invalid_token","enforced_at":"authorization","remedy":"Read this metadata document, then request a token from the authorization server it names, with this resource as the audience."},{"id":"rs.authority_gate","title":"Authority is the RFC 9396 detail type, not a scope","statement":"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.","denial_reason":"insufficient_authority","enforced_at":"authorization","remedy":"Obtain a token carrying the detail type the tool names. Delegation only ever narrows, so the delegating envelope must already contain it."},{"id":"rs.revocation_honoured","title":"A revoked delegation stops working before its tokens expire","statement":"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.","denial_reason":"delegation_revoked","enforced_at":"authorization","remedy":"The customer must grant a fresh delegation. There is no way to appeal a revocation at the resource."},{"id":"rs.dpop_binding","title":"Sender constrained tokens are bound to the key that holds them","statement":"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.","denial_reason":"dpop_proof_required, invalid_dpop_proof, dpop_key_mismatch, dpop_proof_replayed, access_token_not_dpop_bound","enforced_at":"authorization","remedy":"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."},{"id":"rs.request_validity","title":"A malformed request is refused with the reason it was malformed","statement":"Arguments are validated before any business rule runs, and the refusal names the argument at fault rather than returning a bare failure.","denial_reason":"tool_error, invalid_amount, unknown_tool","enforced_at":"execution","remedy":"Correct the named argument. The tool schemas are published in this document."},{"id":"pay.envelope_required","title":"Every payment is counted against a delegation","statement":"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.","denial_reason":"envelope_not_identified","enforced_at":"execution","remedy":"Obtain the token through the delegation chain that begins with the customer approval, so it carries the root_grant of that delegation."},{"id":"pay.token_authority","title":"A payment never exceeds the amount its own token names","statement":"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.","denial_reason":"token_authority_exceeded","enforced_at":"execution","remedy":"Pay no more than the amount the token names, or obtain a token issued for the larger amount from within the same envelope."},{"id":"pay.single_payment_limit","title":"No single agent initiated payment above AUD 20,000.00","statement":"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.","denial_reason":"single_payment_limit_exceeded","enforced_at":"execution","remedy":"Take the payment to a second approver over CIBA and present the token that approval produces."},{"id":"pay.cumulative_envelope","title":"Cumulative spend never exceeds the approved envelope","statement":"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.","denial_reason":"envelope_budget_exceeded","enforced_at":"execution","remedy":"The customer must approve a larger envelope. No approval inside the agent fan out can create headroom that the customer did not grant."},{"id":"pay.no_duplicate_settlement","title":"An invoice is settled once per delegation","statement":"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.","denial_reason":"invoice_already_settled","enforced_at":"execution","remedy":"None. The invoice is paid. A wrong payment is reversed through the bank, not corrected by paying again."},{"id":"pay.purpose_consistency","title":"The payment settles what the grant said it would settle","statement":"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.","denial_reason":"purpose_mismatch","enforced_at":"execution","remedy":"Instruct the payment the token was issued for, or obtain a token for the other one."}],"tools":[{"name":"execute_payment","description":"Instruct a payment against an approved supplier invoice, within the delegated envelope and the single payment limit.","required_authorization_details_type":"payment_initiation","mutates":true,"http_endpoint":"https://rs-payments.demo.cba.raidiam.io/api/execute_payment","mcp_tool":"execute_payment"},{"name":"get_envelope_status","description":"Report how much of the delegated envelope has been settled and how much headroom is left.","required_authorization_details_type":"payment_initiation","mutates":false,"http_endpoint":"https://rs-payments.demo.cba.raidiam.io/api/get_envelope_status","mcp_tool":"get_envelope_status"},{"name":"preflight_payment","description":"Ask whether a payment would be accepted, without making it. Returns the same reason the payment itself would have returned.","required_authorization_details_type":"payment_initiation","mutates":false,"http_endpoint":"https://rs-payments.demo.cba.raidiam.io/api/preflight_payment","mcp_tool":"preflight_payment"}],"interfaces":{"mcp":{"transport":"streamable-http","endpoint":"https://rs-payments.demo.cba.raidiam.io/mcp","description":"Model Context Protocol over Streamable HTTP. The same authority gate applies as on the HTTP endpoints."},"http":{"style":"json","endpoint_template":"https://rs-payments.demo.cba.raidiam.io/api/{tool}","description":"A plain JSON twin of every tool, sharing one handler with the MCP surface."}},"observability":{"decisions_endpoint":"https://rs-payments.demo.cba.raidiam.io/decisions","description":"The most recent admission decisions, allowed and refused, each carrying the policy that decided it and the values the decision turned on.","correlation":{"request_header":"x-correlation-id","also_accepted":["traceparent","access token correlation_id claim","access token txn claim"],"response_header":"x-correlation-id","echoed_in":["the response body of every allowed call","the body of every refusal","every decision log entry"],"lookup":"https://rs-payments.demo.cba.raidiam.io/decisions?correlation_id={id}","description":"Send an identifier from whatever triggered the work and this resource records its decision under that identifier rather than minting its own. One id therefore runs from the trigger, through the token issued for it, to the decision made here, and the decisions taken under it can be read back in order."},"recorded_per_decision":["the correlation id and where it came from","the authorization server, the published key that verified the token, and whether that server was resolved to the configured federation trust anchor","the agent identity that made the call and the full delegation chain behind it, as asserted by the authorization server in the RFC 8693 act claim","the delegating customer and the root delegation","the authorization_details types held against the type the tool required","the outcome, and for a refusal the policy that decided it and the values it turned on"]}}}