Openbanking Event Notification API Specification - TPP Endpoints
Browse all Openbanking APIs✓ Official Vendor SpecFinanceBankingoauth21 EndpointsREST
For Agents
Receive push notifications from UK banks about consent and resource events via the single POST /event-notifications endpoint, secured with TPPOAuth2Security.
Use for: Receive a consent revocation notification from a UK bank, Process a Security Event Token for a resource update, Set up the TPP endpoint that accepts event notifications, Check that an event notification is signed correctly
Not supported: Does not initiate payments, read account data, or check funds availability — use for receiving ASPSP-pushed consent and resource event notifications only.
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.
Install Jentic One Beta
Connect the Event Notification API Specification - TPP Endpoints to your agent
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Event Notification API Specification - TPP Endpoints, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
1
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh2
Step 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
Capabilities
What an agent can do with Event Notification API Specification - TPP Endpoints API.
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
Patterns agents use Event Notification API Specification - TPP Endpoints API for, with concrete tasks.
★ 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.
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.
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.
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.
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
1 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.
METHOD
PATH
DESCRIPTION
POST
/event-notifications
Accept a Security Event Token from an ASPSP
POST
/event-notifications
Accept a Security Event Token from an ASPSP
Why Jentic?
Three things that make agents converge on Jentic-routed access.
Credential isolation
The TPPOAuth2Security client_credentials token used to validate inbound notifications is stored encrypted in the Jentic vault. Agents process events via Jentic and never see the raw bearer used to authenticate the inbound caller.
Intent-based discovery
Agents search Jentic by intent (for example 'receive a uk bank event notification') and Jentic returns the POST /event-notifications operation with its SET payload schema and required scopes.
Time to first call
Direct integration: 2-3 weeks to set up the inbound endpoint, JWT validation, scope enforcement, and audit logging. Through Jentic with credentials provisioned: 1 day to bind the agent handler to the structured event.
Related APIs
Alternatives and complements available in the Jentic catalogue.
FAQs
Specific to using Event Notification API Specification - TPP Endpoints API through Jentic.
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.
GET STARTED