canonical: https://jentic.com/apis/openbanking.org.uk/event-notifications-openapi # Openbanking Event Notification API Specification - TPP Endpoints The UK Open Banking Event Notification API (TPP endpoints) defines how a TPP receives push notifications from a UK ASPSP about consent and resource events. The single endpoint, POST /event-notifications, accepts a Security Event Token (SET) per RFC 8417 from the bank and is secured with TPPOAuth2Security using client_credentials. Events typically cover consent revocations, resource changes, and other lifecycle signals so the TPP no longer needs to poll consent state. ## For AI agents Receive push notifications from UK banks about consent and resource events via the single POST /event-notifications endpoint, secured with TPPOAuth2Security. ## Scope Does not initiate payments, read account data, or check funds availability - use for receiving ASPSP-pushed consent and resource event notifications only. ## Capabilities - Accept Security Event Tokens (SETs) from regulated UK ASPSPs at POST /event-notifications - Replace polling of consent state with push notifications when an ASPSP revokes a consent - Receive resource-update signals so a TPP refreshes cached account, balance, or transaction data - Authorise the inbound notification using the standard TPPOAuth2Security client_credentials flow - Stay aligned with the OBIE Event Notifications standard so the same handler works across all ASPSPs - Reduce request volume against AISP and PISP APIs by reacting to events rather than polling - Log SET payloads for audit and replay if downstream processing fails ## Use cases ### Consent Revocation Handling Replace daily polling of every active consent with push notifications. When a PSU revokes a consent at their bank, the ASPSP sends a Security Event Token to the TPP's /event-notifications endpoint, and the TPP marks the local consent as revoked so it stops issuing AISP or CBPII calls. This is the recommended pattern in the Open Banking standard for keeping consent state in sync. Example prompt: Receive a SET on POST /event-notifications, decode the JWT, and update the consent record matching the events.consent.revoked claim to status='revoked'. ### Resource Update Cache Invalidation Use ASPSP-published resource events to invalidate cached transaction or balance data so the next user view triggers a fresh AISP fetch. The single POST /event-notifications endpoint is the inbound handler; the TPP processes the SET and emits an internal cache-invalidation message keyed to the affected AccountId. Example prompt: On receipt of a resource-update SET, parse the affected AccountId and emit an internal 'aisp.account.invalidated' message to flush the transaction cache. ### Audit Trail for Regulatory Reporting Persist every received SET to an immutable audit log so regulators can review the lifecycle of every consent and event. Because the standard mandates a single inbound endpoint, the audit pipeline is simple - append-only storage of the JWT payload plus receipt timestamp meets typical audit needs. Example prompt: On every POST /event-notifications, append the raw JWT plus received_at timestamp into an append-only audit table keyed by event_id. ### AI Agent Event Handler via Jentic Wire an AI agent into the Event Notification flow through Jentic so it can react to consent or resource events and update downstream systems. Jentic holds the TPPOAuth2Security token in its vault, validates the SET, and surfaces a structured event object to the agent, which then triggers the right follow-up call. Example prompt: Use Jentic search 'receive a uk bank event notification', load the POST /event-notifications schema, and execute the handler that decodes the SET and triggers a downstream cache or consent update. ## Key endpoints | Method | Path | Description | | --- | --- | --- | | POST | /event-notifications | Accept a Security Event Token from an ASPSP | ## Key resources - **EventNotifications** — Single inbound endpoint that accepts a Security Event Token from the ASPSP for a consent or resource event. ## Why Jentic - **Setup:** Wiring the Event Notification TPP endpoint by hand means validating the TPP client_credentials token on inbound calls, parsing the signed SET payload, and mapping ASPSP-pushed events yourself. Through Jentic you install once, import the Event Notification API from the API Directory, store the OAuth credentials once, and your agent calls it. - **Permission scoping:** This surface exposes a single operation that receives event notifications in the request body, so scope it by limiting the agent to the operations it needs, such as posting an inbound event notification. You choose the operations it may call, and nothing beyond that set runs. - **Credential handling:** Your TPP client_credentials token used to validate inbound notifications is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'receive a UK bank event notification', and Jentic returns the POST /event-notifications operation with its SET payload schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **Open Banking Account and Transaction API** — AISP standard whose consent and resource state events flow through this notification API. - **Open Banking Confirmation of Funds** — CBPII standard whose consent revocation events arrive through this notification API. - **Plaid API** — Aggregator that exposes its own webhooks for bank account and transaction events. ## FAQ ### What authentication does the Open Banking Event Notification API use? TPPOAuth2Security with client_credentials. The ASPSP authenticates to the TPP's /event-notifications endpoint using a token issued under this flow, with scopes covering accounts, fundsconfirmations, and payments. Through Jentic the credentials are stored encrypted in the vault and only used for this inbound validation. ### Can I receive consent revocation events through this API? Yes. ASPSPs send a Security Event Token to POST /event-notifications when a consent is revoked. The JWT payload identifies the affected ConsentId so the TPP can mark the local copy as revoked and stop issuing AISP or CBPII calls referencing it. ### What are the rate limits for the Event Notification API? Rate limits are not publicly specified in the standard for the inbound endpoint, since events are driven by PSU and ASPSP actions rather than TPP polling. Sizing is event-driven; in practice the volume is dominated by bulk consent expiry windows. Plan capacity around concurrent SET deliveries during those windows. ### How do I plug this API into a Jentic-driven workflow? Use the Jentic search query 'receive a uk bank event notification', select the POST /event-notifications operation, load its schema, and execute the inbound handler. Jentic decodes the JWT and surfaces a structured event object so the agent can react without parsing the SET manually. ### Does this API support polling for events as a fallback? No. This specification covers only the TPP-side inbound endpoint that accepts pushed Security Event Tokens. If the ASPSP also exposes an aggregated event-polling endpoint, that is described in a separate specification - this one defines a single POST /event-notifications receiver. ### Why is there only one endpoint? By design. The Open Banking standard models event delivery as a push from ASPSP to TPP, so the TPP only needs a single inbound receiver to accept Security Event Tokens. All event types - consent revocation, resource updates - flow through the same endpoint and are differentiated by the SET payload's event claims. ### Can I limit what my agent is allowed to do with the Open Banking Event Notification API? Yes. Because you run Jentic One yourself, your own rules decide which operations and credentials the agent may use with this API. This surface exposes a single operation, POST /event-notifications, which receives inbound Security Event Tokens, so you can scope the agent to just posting an inbound event notification and nothing else. Your TPP client_credentials token stays under your control and is injected only for that inbound validation, never exposed to the agent.