Skip to main content
Tesouro emits the following event types for embedded banking. Every delivery uses the common envelope; each event type below documents the attributes shape and includes an example payload.
attributes.rawData is a verbatim pass-through from the upstream banking core. Tesouro doesn’t control or guarantee its structure, field names, or stability - it can change without notice. Use the documented attributes fields for business logic. Treat rawData as opaque except for debugging and audit.

LEDGER_TRANSACTION

A monetary transaction posted to the ledger.

Attributes

reference is best effort. It’s absent on a posting you didn’t originate, such as a deposit from a third party, and on a transfer you did originate whose settlement path carries no identifier Tesouro can match. Which path a transfer takes depends on how your bank routes that payment rail. Correlate against the transfers list when it has to be reliable.

Example

A LEDGER_TRANSACTION delivery for a $50 ACH pull you initiated with the reference INV-10423, settling as an incoming credit to the account:

LEDGER_POSTING_EXCEPTION

Posting a transaction raised an exception.

Attributes

Same shape as LEDGER_TRANSACTION, with one difference: eventType is always "LEDGER_POSTING_EXCEPTION". rawData carries the upstream exception payload instead of a successful posting.

Example

A posting exception on a transfer you initiated carries that transfer’s reference:

LEDGER_ACCOUNT_EXCEPTION

A ledger account raised an exception.

Attributes

Same shape as LEDGER_TRANSACTION, with two differences: eventType is always "LEDGER_ACCOUNT_EXCEPTION", and routingNumber may be empty. rawData carries the upstream exception payload, and reference never appears.

Example

ACCOUNT_STATUS_CHANGED

A ledger account’s status changed (for example, opened, closed, dormant, or charged off).

Attributes

Same shape as LEDGER_TRANSACTION, with two differences: eventType is always "ACCOUNT_STATUS_CHANGED", and routingNumber is empty. rawData carries the upstream status-change payload, including the new primary and secondary status values. reference never appears.

Example

ACCOUNT_RESTRICTION_CHANGED

A ledger account’s restrictions changed (for example, an account freeze was added for suspected fraud).

Attributes

Same shape as LEDGER_TRANSACTION, with eventType always "ACCOUNT_RESTRICTION_CHANGED". rawData carries the upstream restriction payload, including the action (actnCde is ADD, CHANGE, or DELETE) and the restriction detail. reference never appears.

Example

IDENTITY_VERIFICATION_STATUS_CHANGED

The identity-verification (KYC) status changed for a bank account application. The attributes carry the application, the organization it belongs to, and the status transition.

Attributes

Status values (previousStatus and newStatus):
This event fires only on an actual status transition. Once a transition is queued for delivery, it follows the standard delivery and retry behavior: failed attempts are retried, and you should deduplicate on deliveryId. Separately, forwarding a transition into the webhook pipeline is best effort, so on rare occasions a status change is never queued and no event is sent for it at all. Where correctness matters, reconcile against the kycVerificationStatus field returned by GET /embedded-banking/v1/bank-account-applications/{id} rather than relying on receiving an event for every transition. Its values (PENDING, MANUAL_REVIEW, APPROVED, DENIED) match this event’s newStatus.

Example

An IDENTITY_VERIFICATION_STATUS_CHANGED delivery for an application that cleared manual review and was approved: