Business Events

Financial institutions need to monitor events happening in the various systems that they run, including the
core banking system.
Such events by nature are of interest to either the financial institution themselves or their Customers.
An event could have any number of consequences. Monitoring can be used to either feed a Business Activity
Monitoring system or even used to send an Alert (typically Email or SMS or even as a T24 Secure Message).
Such Alerts normally have been requested by one or more persons.
There are five distinct stages in the life cycle:
 Event Definition
o Define Subscribers for the Event
 Event Detection
 Event Evaluation and Publication
 Allow Request for Alert Notifications
o Manage Requests
 Event Logging
This guide explains the framework behind Business Events Management and how an event detected
transpires into an Alert Notification (for example, an SMS Alert sent to the mobile phone of a Customer when
one of their accounts goes Overdrawn).

Product Overview/Fundamentals:

There are six distinct components in this Product to make this work.

Event Types

 These are really a grouping of similar events into one class.

 For example, “Debit Transaction”

Event Definition

 A sub-set of an Event Type with specific evaluation criteria to qualify

 For example, “Large Withdrawal”, which is a sub-set of Debit Transaction but will be qualified based
on user set parameter of Transaction Amount greater than 5,000.

Touch Points

 These are pre-identified processes in T24 who Detect an Event Type happening.
 Each Event Type is owned by one Touch Point. In other words, the attributes of a Touch Point are
defined by an Event Type.
 For example, T24 Accounting Engine is the Touch Point that detects when a “Debit Transaction”
Event Type happens.
TEC Framework

 The central engine that Evaluates, Qualifies and Publishes an Event.

Alert Request Management

 A facility to allow the Customer or an Account Officer of an Account/Arrangement to request for an

alert when a certain event happens.
 It also allows them to stop getting alerts for an Event.
 Where applicable, this also allows them to specify any additional evaluation criteria.
 For example, an Event called “Balance Goes Below a Certain Threshold” allows the customer/account
officer to specify the actual value, which they would consider as the Threshold. So, one customer
may specify 100 while another specifies 150 at the time of requesting for Alert.

Subscribers

 Other systems that consume the event published by TEC and produce their own output as a result of
such consumption.
 For example, T24 Delivery Module is a subscriber to the events published by TEC and it converts the
event into an SMS or Email message and delivers the Alert. Based on Customer’s Delivery
Preferences, this could also be a postal communication.

Term Definition

Event: An occurrence within T24 – for example, a payment arriving, or an Account Inactive flag being set.

Alert: A message being sent to a customer or account officer, to inform them that the event has occurred. In
future releases, there may be further consequences of Events – for example, Process Workflows being
triggered or external Business Activity Monitoring systems being updated. At present, however, the Delivery
module is the only recipient of Events.

Features Overview

 T24 Model Bank comes with a set of Event Types, Event definitions and T24 Delivery as the
subscriber to these events.
o Such event types are confined to Events happening on a T24 financial product.
 For example, Current Account or a Loan Arrangement

o Such alert notifications can either be requested by the Customers or the Account officers of
those products.
 T24 Model Bank ARC IB comes equipped with a enquiries and screens that guide the customer to
request for an Alert.
 Alerts can be set for ‘one off’ events – for example, clearing of a certain Cheque – where the
Customer is automatically unsubscribed once the event has occurred.
 For balance-related transactions, the system can detect whether the transaction has caused an event
to occur, or happens afterwards (for example – if an alert is set for when the balance goes below
$100, then a transaction taking the balance from $110 to $90 would trigger an alert – but another
transaction taking the balance from $90 to $70 would not trigger another alert).
  If an occurrence has the capability to trigger more than one event (for example, a transaction both
exceeds a permissible amount, and also pushes the account balance beyond an accepted threshold)
it is possible to determine whether one event takes precedence over another, and therefore only
one of those events is triggered.
 An event may be set to active/inactive at the definition level – this affects all parties subscribing to
that event (for example, if the bank wishes to temporarily suspend some types of alerts, or wishes to
do setup in advance before switching alerts on).

Business Events Configuration

Before delving into the details of the Alerts and Notifications functionality, it is important to understand the
significance of ‘Event Types’ or in other words, ‘Pattern’ of events.

The purpose of the ‘Event Type’ is to allow implementations to add more events without any additional code.
At the same time, the Event type should not be at such a high level and generic as to be able to fit 100 events
into one bucket.

It is anticipated that the event types identified here may not cover absolutely every event that could happen
in a banking system and there could certainly be some exceptions to these patterns.

The rationale is to prevent this minority of exceptions from impeding the performance of the majority of
most common events.

An event type is a classical grouping of similar events into a group. For example, consider the following
events.

When an account is credited and the credit amount is greater than 5,000 (“Large Deposit”)

When an account is credited and the transaction code is a ‘Salary Credit’

Whenever an account is credited

All of these events can be logically grouped under an Event Type called “CR.TXN” and supplemented with
additional criteria based on values in the fields in respective STMT.ENTRY records.

When an account is debited and the debit amount is greater than 5,000 (“Large Withdrawal”)

When an account is debited and the Channel is ATM POS (Point Of Sale) purchase.

Whenever an account is debited:

All of these events can be logically grouped under an Event Type called “DR.TXN” and supplemented with
additional criteria based on values in the fields in respective STMT.ENTRY records.

It is indeed possible to group all the above into one type called “TXN” but that would move the level of
grouping to one level higher, which in turn increases the unnecessary processing that would be done by TEC
every time an event occurs.

Architecture of Events
There are two underlying parameter tables used for Event Definition: these are EB.EVENT.TYPE and
TEC.ITEMS. These two are discussed below:

EB.EVENT.TYPE

EB.EVENT.TYPE is the touchpoint between the actual event happening in T24 and the TEC.ITEMS
configuration. T24 Model Bank supplies a number of ‘touchpoints’ whereby an event can be indicated to
have happened.

The majority of touchpoints are instances where a table is updated. However, there are also some
touchpoints, which are not triggered from the update of a table – for example, Direct Debit and Standing
Order executions and failures.

When an EB.EVENT.TYPE is called, it can also supply the delivery instructions that should result from this
event type - an EB.ACTIVITY value is specified, which in turn links to an EB.ADVICES record, which in turn link
to the DE.MESSAGE functionality.

TEC.ITEMS

This table handles both technical alerts (errors in processing) and business alerts (information for customers
and account officers about business events).

It is likely that the overall touchpoint is too high-level to be of use for determining an event. For example, we
may not want to know every time a record changes - but we want to know when a particular field on that
record changes.

Through TEC.ITEMS, the bank can fine-tune the nature of the event – we may not want an event to be
generated every time a ‘touchpoint’ (EB.EVENT.TYPE) is triggered, but possibly under specific circumstances.
It is to these fine-tuned circumstances that the user then subscribes. TEC.ITEMS clarifies the nature of the
Event through the following settings:
Subscriber

When an event occurs, through which medium should the alert be communicated? Model Bank comes
configured with the functionality to communicate this over the DELIVERY system. In future, other subscribers
such as Process Workflow or a Business Activity Monitoring mechanism may be included.

Which Event type is being used? (i.e. what is the underlying touchpoint) – This is set in the EVENT.TYPE field.

Subscription Type

Will this event be monitored by customers, account officers, both, or will it be mandatory for everyone
affected? - This is set in the SUBSCRIPTION.LEVEL field. There are queries in model bank, and validation to
ensure that internal subscribers (account officers) cannot subscribe to external events, and vice-versa.

Field level specification

 Where an event relates to entry into a T24 table (this tends to be the main source of events), what
checking should the system perform to ascertain whether an event has taken place? For example,
events may be related to an update to the ACCOUNT table (so update to ACCOUNT is the touchpoint)
– but different events can be derived from this, depending on whether it is the WORKING.BALANCE
or ACCOUNT.INACTIVE or even CURR.NO fields on account. Additional considerations :
o An event might only occur depending on updates to two or more fields – for example, an
event might only be triggered if the WORKING.BALANCE field changes and the
CATEGORY.CODE is in the range 1000 – 1999.
o Operands: Event functionality can compare new with old values to determine whether an
event has occurred. Therefore, along with the usual operands (greater than, less than, begins
with, ends with, equals, does not equal, is/is not in the range of, etc) there are also
comparative operands: changed, changed from, and changed to.
o Where the EVENT.TYPE is based on a table, the same table should be entered in the TABLE
field.
o Along with being determined by one or more fields, an event may be defined by a KEYWORD.
See section on KEYWORDS for more information

Subscriber Level Definitions

Events themselves may have subscriber (Customer or Account Officer) variables, which determine whether
the event has happened – so one customer may wish to be alerted to an event when their working balance
falls below 500, another may wish to be alerted only when the working balance falls below 100. Whether a
subscriber will be required to set their variable is set in the INHERIT field within the FIELD.TYPE – INHERIT
multivalue set.

Precedence

It is likely that some events may take precedence over others – for example, I may have an event to alert me
when my balance falls below 100, and another event, which alerts me when my overdraft limit is exceeded.
In this case, I might want to only receive the second alert if a single transaction triggers both alerts. This is set
in the PRECEDENCE field.

One Time Subscription

An event might be a ‘one-time-only’ occurrence – for example, I may wish to be alerted when a chequebook
is issued, or a loan is authorized. Once this has happened, and the alert has been issued, the event should be
automatically ‘unsubscribed’ – as it would be unnecessary and inefficient for the customer to have to
unsubscribe to it. This would be specified in the ONE.TIME.SUB field.

Event Severity

Severity – Each TEC.ITEMS can be classified with a severity level. This is used for information/reporting
purposes. It can be used to determine the alert carrier.

Active / Inactive

A TEC.ITEMS can be switched on/off for all subscribers through a STATUS field. When it is set to ‘Inactive’
then this TEC.ITEM will not be triggered.

Keywords

Sometimes, it may not be possible to determine whether an event has happened purely through looking at
the fields that were used, and the values in them. Examples of these could be an event being raised when:

A record is reversed (so event based on FUNCTION used).

A particular VERSION is used.

After the FIRST authorizer (not necessarily the final authorizer)

A particular CHANNEL is used (so an event occurs if channel A is used, but not channel B)

A particular APPLICATION is used

To cover this requirement, it is possible to use Keywords rather than a specific table. Keywords allowed are:

- !APPLICATION (Application)

- !V$FUNCTION ( Function)

- !PGM.VERSION( Version of the Application)

- !CHANNEL ( Channel defined in OFS.SOURCE)

- !AUTH.NO ( No of Authorisers)

Steps to Define an Event

To configure an event, apply the following steps:

Identify/Configure the message that should be sent (EB.ADVICES, EB.ACTIVITY).

Identify the ‘touchpoint’ behind the event. Ensure it has the correct message specified.
Create the TEC.ITEMS, specifying the touchpoint and the additional specifics to identify when an event will be
triggered.

Once the event has been configured, to test, create an EB.ALERT.REQUEST to subscribe to the above
TEC.ITEMS record, including any variables that need to be entered (due to the INHERIT flag being set on
TEC.ITEMS), and update T24 in such a way to trigger the EB.ALERT.REQUEST. Review the EVENT.LOG files to
confirm that an alert was triggered in line with the configuration.

Note, in order for events to be processed in order to generate alerts, the relevant services need to be run.

Business Event Services

The following services are associated with Business Events.

Of the below, only EVENT is specific to business events. The others relate to other functionality in the
system; however they are necessary for events to generate delivery messages.

COB Dependent /
Service Name What the service does Stage / Trigger Related
Online Processes
Needs to be run in order to process the events. When this
service is run, records from FBNK.EVENT.LIST are selected and
EVENT Online
processed, to create Delivery Messages, or whatever has been
specified by the TEC.ITEMS and EVENT.TYPE
Supports delivery, to create messages generated through
OFS.MESSAGE.SERVICE Online
Events
SECUREMSG.OUT Generates secure messages Online
EMAIL.OUT Generates emails Online
SMS.OUT Generates SMS Online

Configuring an Account Officer to receive Alerts

Account Officers can receive Alerts on Events in the same way that customers do. However, as customers
have the DE.CUSTOMER.PREFERENCE functionality to receive alerts; Account Officers need to be associated
with a Proxy Customer in order to make use of the same functionality. Therefore, on ACCOUNT.OFFICER
there is a field CUSTOMER.ID through which, an Account Officer can be linked to a proxy customer, where
the Delivery Preferences have been set. A process workflow has been configured for model bank to deliver
this functionality.

When an account officer is linked with an Event, that request is stored on that Account Officer record.
Link an Account Officer to an Event
This How to Guide explains and shows you how an Account Officer can subscribe to a particular event (e.g.
‘Tell me when a new Current Account is opened’)

Prerequisites

This Guide assumes you are using T24 Release: R10

This Guide assumes you have installed these T24 Products: BE

Scenario

In this scenario, an account officer wishes to be linked to an event, so they receive an alert message
whenever this event occurs.

The event we will be choosing is 'Tell me when a new Current Account is opened'.

Once subscribed, the account officer will be told whenever a Current Account is created for which they are
responsible (where they appear in the Account Officer field).

Solution
Step 1 - Configure Account Officers to Receive Events

The Account Officer needs to be linked to a ‘Proxy Customer’, using their Delivery Preferences, in order to
receive Alerts about Events. If the Account Officer specified has not been configured to receive these Alerts,
this needs to be set up before the Account Officer can receive alerts.

Note, there is no dependency – the Account Officer can be linked to Events without being associated with a
dummy customer, however until they are linked no messages will be sent to the Account Officer when an
event occurs.

If the account officer has not already been configured to receive events, follow steps in How To Configure an
Account Officer to Receive Alerts before continuing on this flow.

Step 2 - Open Alerts Management Screen

The Alerts Management Screen can be found under User Menu > Alerts Management.

Step 3 - Select Alert that Account Officer will be subscribed to

From here, a composite screen is launched. We are interested in the second tab, Alert Subscription DAO.
After the administrator clicks this, they may locate the Alert Definition that the Account Officer should be
subscribed to, and select ‘Subscribe’.

Step 4 - Specify the account officer for whom the Event should occur

The Event chosen is defaulted into the event Field. The Administrator now just needs to enter the Account
Officer code and commit the record, and that officer is subscribed to this event.

Note, for this scenario, there are no further ‘conditions’ applied here – as the Event Definition for the event
chosen (ACCOUNT.NEW.CURRENT) does not allow for any variables (e.g the Account Officer cannot specify
which types of accounts they are subscribed for – this is fixed in the Event Definition.

Once this record has been committed, this account officer is now subscribed to this event.
Therefore, in this scenario, whenever a current account is opened by a customer which is managed by this
account officer the Account Officer will be alerted.

The account officer will not be alerted whenever ANY current account is opened – only those accounts where
the Account Officer is the one specified in this record.

Step 5 - Test the Configuration

For the above configuration, we have set an account officer up so that they will be alerted whenever one of
their customers opens a Current Account.

Therefore, to test this, we need to create a Customer who is owned by the alerted Account Officer (130). We
then need to create a Current Account for this customer. As a result, the Account Officer should be alerted
that a new Account has been generated.

Step 5.1 Create New Customer

Using ‘Individual Customer’ option from User Menu:

We input a customer record, specifying our configured Account Officer in the Account Officer field:

Note: Check if the record has been authorised (if it has not, then authorise it).
Step 5.2 Create new Account using the above customer

Using Model Bank Menu structure, we specify ‘Open Current Account’:

By default, we do not need to specify the account officer, and it should be defaulted from the customer
record:

Again, check if the record that has been authorised, If not, authorise it.

Step 5.3: Check Event-based Secure Messages for this Account Officer

This step is purely for those who wish to see the activity 'behind the scenes'. No action is required.

When the account is created, following the EVENT service has run, an EVENT.LOG record is created
In addition, a DELIVERY reference is created, which provides the data for the secure message:

We can find the ‘Event Based Messages’ on the Internet Banking Administration menu
The launched enquiry (MAIL.EVENT) allows the user to specify the account officer for which we are expecting
Event-based messages:

The enquiry results show all the secure messages for this account officer based on events:
When we drill down, we receive the actual message:

How to Configure an Account Officer to Receive Alerts

Summary

Just like a customer, an Account Officer may wish to be informed of Alerts through a number of means –
Email, SMS, Secure Message and so on.

Therefore, T24 uses the DE.CUSTOMER.PREFERENCES functionality to specify how an Account Officer is
informed of an Alert.

In order for this to be done, a Customer record needs to be created, and linked to the Department Account
Officer record.
A process workflow has been created to smooth this process.

This How To will take the user through this process workflow.

Aim

This How to Guide will explain and show you how to set up an Account Officer so they are able to receive
Alerts.

Pre-requisites

This Guide assumes you are using T24 Release: R10 Model Bank

This Guide assumes you have installed these T24 Products: BE (Business Events)

Scenario

Administrator / Account Officer needs to be set up so they can begin to receive alerts.

Solution

Step 1: Launch Process

From the Admin Menu, under Alerts Administration, there is a menu item for ‘Set Acct Officer for Alerts’.
Step 2: Provide Contact Information

The process launches a screen where the user specifies the Account Officer's contact information in a proxy
customer.

Step 3: Process defaults customer onto Account Officer record

The process automatically launches the account officer record, and defaults the newly created customer
onto this record. The user is not required to do anything beyond committing the record.
Step 4: Specify Delivery Preferences

With the Account Officer now linked to this customer, we now specify the delivery preferences. These
preferences will then be applied to this Account Officer, through the customer. In the following setup, the
Account Officer will be communicated through Secure Message:

Step 5: Test Configuration – Subscribe to Events

Now that the Account Officer is set to be able to receive alerts, they can subscribe to events.