Introduction

Providing the ability for customers to set and receive alerts regarding the state of their finances is a big win for Financial Institutions. People are busy but need to keep a sharp eye on the state of various accounts and transactions. Alerts provide automation to customers, so they can handle financial situations proactively.

Alerts, in the Candescent Digital Banking Platform, are managed through a suite of APIs:

• Alert Types API
• Alert Templates API
• Alert Preferences API
• Alert Events API
• Alert History API

The first two of these, Alert Types and Alert Templates, are used by the FI to establish what alerts are available to customers (e.g. Low Balance, High Balance, Large Transaction) and the content of those alerts by channel (e.g. SMS, Email)

The third, Alert Preferences, provides the capability for a customer to set an alert (e.g., "Alert me when my checking balance is below $100).

The next, Alert Events, is the bridge between the event occurring and the alert being sent. An alert that has been defined is published using this API. (e.g. Bill’s checking balance is below $100. He set an alert to send SMS when this occurs. Here is the template of what to send via email, Send the alert).

The last, Alert History API, can be used to retrieve alerts that have been published using a variety of parameters (by account, date range, status, etc.

Value

Alert Types API

To the FI:** Setting up a suite of alert types gives your customers a robust set of options to select for alert notifications. It also simplifies the process of user alert creation. The user can select from the suite of alert types configured.

To the Developer: In conjunction with the suite of Alert capabilities, this API supports the creation, retrieval, updating and deleting of all alert types set for a given FI.

Alert Templates API

To the FI: Setting up a suite of alert templates assigns the content and context of the communication for each event type and channel. The template is then called up and used for each event occurrence that matches the type and user preference setting.

To the Developer: In conjunction with the suite of Alert capabilities, this API supports the creation, retrieval, updating and deleting of all alert templates for a given FI.

Alert Preferences API

To the FI: This service gives the end user the ability to create multiple alerts based on how they want to manage their finances. Making such a system easy and intuitive is a solid win with customers.

To the Developer: In conjunction with the suite of Alert capabilities, this API supports the creation, retrieval, updating and deleting of all alert preferences for the customer of an FI.

Alert Events API

To the FI: This is where the rubber meets the road - the link between an event and the alert being sent to the customer. All the preparation, the Alert Types, Templates and Preferences, come together when an event uses this API to trigger the communication.

To the Developer: In conjunction with the suite of Alert capabilities, this API is called by an application based on a condition that is set to trigger an alert.

Alert History API

To the FI: Retrieving alert history can be used to determine of correct alerts are being sent, to determine if a customer has been properly alerted, to determine patterns of alert activity, and other analysis and reporting needs.

To the Developer: Building Alert systems for the FI and the customer will be enhanced by the ability to retrieve alert history data.

What is Supported

The Alert Types API provides methods for carrying out the following tasks:

• CREATE: The Create method of the API establishes a particular Alert Type.
  • The type is set for a given FI, set to a unique ID value, named, and set to be ACTIVE (available for use) or INACTIVE
  • The specific alert type available in the system is set (e.g., ‘ATM Withdrawal’ or ‘Visa Low Balance’)
  • The broad domain of alert event is set (e.g., an Account event, a Transaction event, or a Notification event)
  • The category of event is set (e.g., Balance, Payment)
  • The account yptes that can use this eventy type are enumerated
  • The channels the event notification can use are idnetified (e.g. Email or SMS)
  • If the Alert Type is for an external vendor event, the vendor ID is set.
• READ: A list of all created Alert Types can be retrieved using this method
  • The values set for each Alert Type stored are sent in the response
  • All Types created, active or inactive are retrieved.
• UPDATE: values for existing Alert Type records can be updated and modified.
• DELETE: Specific Alert Types no longer needed can be deleted from the database.

The Alert Templates API provides methods for carrying out the following tasks:

• CREATE: The Create method of the API establishes a particular Alert Template.
  • The template is set for a particular FI, given a unique ID value, named, and set to be in DRAFT, ARCHIVED or PUBLISHED state.
  • The types of content the template can be used with are identified (e.g., EMAIL_SUBJECT,EMAIL_BODY,SMS_BODY, etc.)
  • The channel through which the template can be used is identified: (EMAIL / SMS / PUSH)
  • If the template is for an event initiated by a third party, the TPV is named
  • The language (i.e “Locale”) of the template is identified (US English, Spanish, etc.)
• READ: A list of all created Alert Templates can be retrieved using this method
  • The values set for each Alert Template stored are sent in the response
  • All Templates created, whether in DRAFT, ARCHIVED or PUBLISHED state, are retrieved
• UPDATE: values for existing Alert Template records can be updated and modified.
• DELETE: Specific Alert Templates no longer needed can be deleted from the database.

The Alert Preferences API provides methods for carrying out the following tasks:

• CREATE: The Create method of this API establishes an alert the customer wants to e triggered for a particular event. Some characteristics of an Alert Preference are:
  • A unique ID for the preference record, Financial Institution ID, Customer ID, a name of the alert, and a flag to set the alert preferences as a default for a particular event.
  • The channels the alert is to use for communication - EMAIL,PUSH,SMS
  • If the event will come from an external vendor, the ID of the external vendor
  • The account to be watched for an event - identified by the FI’s account number, card number, or external account number
• READ: This call can be used by the customer, to call up and review some or all created preferences. It is also used when an event occurs, to read and use the preferences set by the customer.
  • The call can be filtered by a variety of criteria, including alert type, account, and institution ID.
• UPDATE: values for existing Alert Preferences records can be updated and modified.
• DELETE: Specific Alert Preferences no longer needed can be deleted from the database.

The Alert Events API provides only one method, a call to indicate that an event has occurred. The API then in turn takes the data passed in the request and initiates the sending of the Alert. It uses the resources previously established - the Alert Type and its associated Template, and the customer’s Preferences, to send the alert notification. The inbound call to this API will indicate the event is one of two possible types:

• An Event - related to the customer’s Accounts or Transactions (e.g., The checking account balance is below a set threshold. A payment exceeds a set threshold.)
• A Notification - A message sent by an external party (such as VISA) which requires no processing by the Alerts system itself, that must be sent to the customer.

The Alert History API provides methods for carrying out the following tasks:

• READ: Get alert history data using parameters (account, date, etc.)
• READ: Get alert history data using content, history or event IDs

Additional Product Details

Alert Type Resource Model

Following are the fields and values for an Alert Type record

Alert Templates Resource Model

Following are the fields and values for an Alert Template record

Alert Preference Resource Models

The resource model for preferences includes several interlocking models - the preference record, the account affected, and details of the preference settings:

AlertPreference

**

AlertPreferenceDetails

AlertPreferenceAccountDetails

**

AlertPreferences

Alert Events Resource Models

The resource model for an event requires different data based on type (Account, Transaction, Notification), then contains a base set of data common to all.

AccountEvent (extends Event)

TransactionEvent (extends Event)

NotificationEvent (extends Event)

Notification

EventDetails