General Structure

When an event happens, an event message is created with data about the event that was triggered. Event messages are structured to contain both information that is common to all events and data that is unique for the specific type of event. Event data is always provided in JSON format.

Event messages include information such as who or what triggered the event, when the event was triggered, and what was the type of event. The type of event message indicates what event was triggered, such as the creation of a wire transfer. There can be many event messages over time for each type.

Each event message type belongs to an event category, such as profile or transfers. For example, events for updating an email address or updating a physical address fall under the the profile category.

All event messages contain a consistent set of data regardless of event type. An individual event message is defined using the eventMessageItem schema, which includes attributes such as the occurredAt date. The schema can be viewed for further details on the data available.

While every event message has certain shared data properties, each type of event can have event-specific data in the data object. For example, if the event trigger was an address being updated, the data object is defined with the addressUpdatedEventSchema. This specific schema contains information about the address change that would not be included with an event that doesn’t affect addresses, such as logging in.

The schema name for an eventMessageItem‘s data object is the event message’s type name followed by EventSchema. For example, a data object eventMessageItem with type of addressUpdated is defined by the addressUpdatedEventSchema.

If a property is not needed for an event message, that property is omitted. For example, the secondaryId property is used to store a second resource that an event affected, but many events do not affect more than one resource.

All of the event messages recorded during a range of time are available in a JSON eventMessages object.

A list of event specific schemas is listed below:

Category	Event Type and Schema	Trigger
`accounts`	`fullAccountNumberAccessed`	User accessed a full, unmasked internal account number
`accountApplications`	`accountApplicationApproved`	The system or an admin user approves the account application.
`accountApplications`	`accountApplicationBlocked`	The system marks this account application as blocked. The application is waiting for review or for the completion of an external activity.
`accountApplications`	`accountApplicationCanceled`	User or FI admin cancels a new account application or cancels a joint owner application.
`accountApplications`	`accountApplicationCreated`	User creates an account application. Applies to both new accounts and invitations to add joint owner to an existing account. An application is considered created when the user completes the first page of the application, which collects basic info including their full name and date of birth. This event is typically followed by a `accountApplicationStarted` event.
`accountApplications`	`accountApplicationStarted`	User starts a new account application or a joint owner application. The user must progress through the second page of the application for it to be considered started, not only created. The second page of the application includes the users address and other personal information. This event typically follows an `accountApplicationCreated` event.
`accountApplications`	`jointOwnerApplicationApproved`	FI approves a joint owner application for access to a banking account.
`authentication`	`identityChallengeFailed`	User fails an identity challenge. The failure count is reset after 24 hours. Using expired passcodes does not count as a failure.
`authentication`	`identityChallengeInitiated`	User initiates an identity challenge for an operation that requires proof of identity. For example, a user may request a one-time passcode is sent to their email address.
`authentication`	`identityChallengeSucceeded`	User successfully completes an identity challenge.
`authentication`	`mfaFailed`	During login, the user failed a multi-factor authentication (MFA) challenge
`authentication`	`mfaInitiated`	During login, the user began the multi-factor authentication (MFA)
`authentication`	`mfaSucceeded`	During login, the user successfully completed multi-factor authentication (MFA)
`authentication`	`passwordUpdated`	User updates their password
`authentication`	`passwordUpdateFailed`	User attempted to update their password but failed. Applies to both authenticated updates and updates using temporary passwords
`authentication`	`userLoggedIn`	User has logged in
`authentication`	`userLoginFailed`	User failed a login attempt
`authentication`	`usernameUpdated`	User updated their username (access ID)
`businessAchTransfers`	`achBatchPaymentApproved`	User approves an ACH batch payment. When multiple approvals are required, the final approval will generate both `achBatchPaymentApproved` and `achBatchPaymentScheduled` events.
`businessAchTransfers`	`achBatchPaymentInitiated`	The system begins processing an ACH batch payment.
`businessAchTransfers`	`achBatchPaymentRejected`	User rejects an ACH batch payment.
`businessAchTransfers`	`achBatchPaymentReversed`	User reverses an ACH batch payment. This event is used for both full and partial reversals.
`businessAchTransfers`	`achBatchPaymentScheduled`	The system schedules an ACH batch payment. This occurs when a user makes the only or final approval.
`businessAchTransfers`	`achBatchPaymentSubmitted`	User submits an ACH batch payment.
`businessAchTransfers`	`achBatchPaymentUnlocked`	User unapproves or unlocks an ACH batch payment.
`entitlements`	`accountOwnerEntitled`	User is granted an ownership entitlement of a banking account. This includes joint ownership.
`entitlements`	`entitlementUpdated`	User changes account or customer entitlements for another customer.
`externalAccounts`	`externalAccountActivated`	User successfully verifies an external account OR an FI administrator manually adds an external account in FXIM. Either action activates the account.
`externalAccounts`	`externalAccountEntitled`	The system grants a user entitlements to an external banking account.
`externalAccounts`	`externalAccountRemoved`	User OR an FI administrator unlinks or removes an external account.
`externalAccounts`	`externalAccountRequested`	User requests to link an external ACH banking account to transfer funds between this financial institution and the external account.
`externalAccounts`	`externalAccountVerificationBlocked`	When micro-deposits are blocked waiting for the micro-deposit transactions to be recorded against the external account or waiting for the user to enter the micro-deposit values to verify the user has account ownership.
`externalAccounts`	`externalAccountVerificationFailed`	User failed to verify ownership of an external account.
`externalAccounts`	`externalAccountVerificationRemoved`	User removes a micro-deposit account verification. May occur when micro-deposit verifications are blocked waiting for the remote transactions to complete.
`externalAccounts`	`externalAccountVerified`	User successfully verified ownership of an external account.
`externalAccounts`	`fullExternalAccountNumberAccessed`	User accessed a full unmasked external account number
`profile`	`addressUpdated`	User updates their postal address
`profile`	`mobileDeviceRegistrationDeleted`	User OR an FI administrator deletes a registered mobile device. The device is unable to log into the mobile banking application until it has been re-registered.
`profile`	`primaryEmailUpdated`	User changes their primary email address
`profile`	`phoneNumberUpdated`	User changed their phone number
`profile`	`smsConsentUpdated`	User changed their SMS notification consent or changed their mobile number
`transfers`	`singleTransferCreated`	User creates a single account-to-account transfer
`transfers`	`singleTransferCanceled`	A user or the system canceled a transfer
`transfers`	`singleTransferFailed`	System fails to process a single account-to-account transfer. Only triggers when the transfer will not be retried automatically.
`transfers`	`singleTransferInitiated`	FI starts processing a single, scheduled account-to-account transfer
`transfers`	`singleTransferProcessed`	Single account-to-account transfer completes processing. Note: This is confirmation that ADB has completed processing the transfer. This is not confirmation of successful delivery of the funds.
`transfers`	`singleTransferScheduled`	User schedules a single account-to-account transfer
`transfers`	`singleTransferUpdated`	User updates a single account-to-account transfer
`wireTransfers`	`wireTransferApproved`	A user approved a wire transfer (More approvals may still be required)
`wireTransfers`	`wireTransferBeneficiaryUpdated`	User changes a wire transfer beneficiary
`wireTransfers`	`wireTransferCreated`	User creates a wire transfer
`wireTransfers`	`wireTransferInitiated`	FI initiates a wire transfer through the wire network.
`wireTransfers`	`wireTransferScheduled`	User scheduled a wire transfer

For more information on the events API, click here to read the full API documentation.

Example Event Messages

An event in an eventMessages collection may look like the data below in a JSON format:

				
					{
  "items": [
    {
      "agentId": "38077708",
      "agentType": "customer",
      "category": "transfers",
      "correlationId": "d91051ff-1ad9-4c90-aad1-a70085065448",
      "id": "f84f8957-c75d-4e29-ba5e-0deff0dfb7ed",
      "institutionId": "FOO",
      "occurredAt": "2022-12-22T16:32:21.130Z",
      "sessionId": "12371980888",
      "type": "singleTransferCreated",
      "data": {
        "sourceAccount": {
          "id": 6439985,
          "maskedNumber": "*0058",
          "routingNumber": "06100010"
        },
        "targetAccount": {
          "id": 17629945,
          "maskedNumber": "*6381",
          "routingNumber": "06100010"
        }
      }
    }
  ],
  "version": "0.1.0"
}

For more specific information on specific fields or other events, visit the full API documentation.