attributes shape and includes an example payload.
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
ALEDGER_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’sreference:
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, witheventType 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. Theattributes 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
AnIDENTITY_VERIFICATION_STATUS_CHANGED delivery for an application that cleared manual review and was approved: