U.S. patent application number 16/517343 was filed with the patent office on 2020-01-23 for systems and methods for alert services.
The applicant listed for this patent is BANK OF MONTREAL. Invention is credited to Yishi LIU, Ching Leong WAN.
Application Number | 20200028701 16/517343 |
Document ID | / |
Family ID | 69162540 |
Filed Date | 2020-01-23 |
View All Diagrams
United States Patent
Application |
20200028701 |
Kind Code |
A1 |
LIU; Yishi ; et al. |
January 23, 2020 |
SYSTEMS AND METHODS FOR ALERT SERVICES
Abstract
Embodiments relate to systems, processes and devices for an
information delivery platform or data hub with an alert processor
that can be configured to receive a request to generate an alert
configuration at the data hub, the request indicating a target
unit; generate and store an alert rule corresponding to the alert
configuration, the alert rule having a trigger and an action;
detect an event at the data hub based on a set of data of the data
stored at the data hub, the event having event data; convert the
event data to an alert trigger at the data hub based on the trigger
of the alert rule; generate an alert notification for the alert
trigger based on the action of the alert rule; and transmit the
alert notification to the target unit.
Inventors: |
LIU; Yishi; (Mississauga,
CA) ; WAN; Ching Leong; (Toronto, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
BANK OF MONTREAL |
Toronto |
|
CA |
|
|
Family ID: |
69162540 |
Appl. No.: |
16/517343 |
Filed: |
July 19, 2019 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62700385 |
Jul 19, 2018 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 12/1895 20130101;
H04L 51/14 20130101; H04L 51/30 20130101; G06F 16/735 20190101;
H04W 68/005 20130101; G06F 16/7844 20190101; G06F 16/9535
20190101 |
International
Class: |
H04L 12/18 20060101
H04L012/18; H04W 68/00 20060101 H04W068/00; G06F 16/735 20060101
G06F016/735; G06F 16/9535 20060101 G06F016/9535; G06F 16/783
20060101 G06F016/783 |
Claims
1. A system for generating alert notifications, comprising at least
a processor and a non-transient data memory storage, the data
memory storage containing machine-readable instructions for
execution by the processor, the machine-readable instructions
configured to, when executed by the processor, provide an alert
service configured to: load and store data from a plurality of
source systems at a data hub implemented by a non-transient data
store; receive a request for an alert subscription at the data hub,
the request indicating a subscriber and an alert configurations;
generate and store an alert rule corresponding to the alert
configuration, the alert rule having a trigger and an action;
detect an event at the data hub based on correlated event data of
the data stored at the data hub, the correlated event data
corresponding to the trigger of the alert rule, the correlated
event data based on in-memory event correlation and computing for
real-time detection; generate an alert notification for the alert
trigger based on the action of the alert rule; and transmit the
alert notification to the subscriber based on the subscription.
2. The system of claim 1, wherein the subscriber is linked to an
alert format and the alert service is configured to generate alert
data using the event data, format the alert data based on the alert
format of the target unit, generate the alert notification based on
the alert data, and generate alert processing result data.
3. The system of claim 1, wherein the alert notification is
assigned an alert identifier and wherein the processor stores data
for the alert notification and the alert identifier in a history
log.
4. The system of claim 1, wherein the alert notification is
assigned an action identifier based on the action of the alert
rule, wherein the action identifier is a pointer to code for adding
the action to the alert notification.
5. The system of claim 3 further comprising an alert handler
configured to monitor the alert notification for user response and
record the user response in association with the alert
identifier.
6. The system of claim 1 further comprising an alert subscription
service configured to store a mapping between a customer
identifier, customer preferences, and the alert rule, the
subscriber being linked to the customer identifier.
7. The system of claim 1 further comprising an application
programming interface to receive the request for the alert
subscription.
8. The system of claim 1 further comprising an alerts catalogue for
storing the alert rule.
9. The system of claim 1 further comprising providing an alert
template to define the alert configuration for the alert
subscription.
10. The system of claim 1 wherein the processor integrates
in-memory event detection and alert notification with the data
hub.
11. A non-transitory machine-readable medium storing instructions
configured to, when executed by the processor, provide an alert
service configured to: receive a request for an alert subscription
at a data hub, the request indicating a subscriber and an alert
configurations, the data hub storing data from a plurality of
source systems, the data hub implemented by a non-transient data
store; generate and store an alert rule corresponding to the alert
configuration; detect an event at the data hub based on correlated
event data of the data stored at the data hub, the correlated event
data corresponding to the alert rule, the correlated event data
based on in-memory event correlation and computing for real-time
detection; generate an alert notification based on the alert rule;
and transmit the alert notification to the subscriber based on the
subscription.
12. The machine-readable medium of claim 11, wherein the subscriber
is linked to an alert format and the alert service is configured to
generate alert data using the event data, format the alert data
based on the alert format of the target unit, generate the alert
notification based on the alert data, and generate alert processing
result data.
13. The machine-readable medium of claim 11, wherein the alert
notification is assigned an alert identifier for storing in a
history log.
14. The machine-readable medium of claim 11, wherein the alert
notification is assigned an identifier based on the alert rule,
wherein the action identifier is a pointer to code for the alert
notification.
15. The machine-readable medium of claim 14 wherein the alert
service has an alert handler configured to monitor the alert
notification for user response and record the user response in
association with the alert identifier.
16. The machine-readable medium of claim 11 wherein the alert
service has an alert subscription service configured to store a
mapping between a customer identifier, customer preferences, and
the alert rule, the subscriber being linked to the customer
identifier.
17. The machine-readable medium of claim 11 further comprising an
application programming interface to receive the request for the
alert subscription.
18. The machine-readable medium of claim 11 further comprising an
alerts catalogue for storing the alert rule.
19. The machine-readable medium of claim 11 further comprising
providing an alert template to define the alert configuration for
the alert subscription.
20. The machine-readable medium of claim 11 wherein instructions
integrate the data hub with in-memory event detection and alert
notification.
Description
CROSS REFERENCE TO RELATED APPLICATION
[0001] This application claims priority to U.S. Provisional
Application No. 62/700,385 entitled SYSTEMS AND METHODS FOR ALERT
SERVICES, the contents of which is hereby incorporated by
reference. This application relates to U.S. application Ser. No.
16/517,253 entitled SYSTEMS AND METHODS FOR DATA STORAGE AND
PROCESSING, the contents of which is hereby incorporated by
reference.
FIELD
[0002] The present disclosure generally relates to the field of
data storage systems and alert processing.
INTRODUCTION
[0003] A full-service financial service institution depends heavily
on the use of technology to serve customers with a wide range of
products and services. In addition, technology is used to meet
stringent risk management and regulatory compliance.
[0004] An organization with a long history typically has adopted a
myriad range of technologies from legacy platforms like mainframe
to modern capabilities like mobile and analytic applications. An
organization might have a large set of applications (many hundreds)
through acquisition and integration.
[0005] To continue to deliver differentiating customer experience
and transformation to keep pace or leap-frog competitors, both
traditional and disruptive ones, an institution needs to be able to
effectively and efficiently integrate the complex and diverse set
of applications. An integrated enterprise not only forms the
foundational capability to deliver any product and service across
different channels, it also enables the ability to identify events
and generates actionable insights to become an intelligent
institution.
SUMMARY
[0006] Embodiments described herein generate alerts for
customers/users who have a subscription to receive such alerts
based on a set of defined events. Functions can be exposed via
APIs.
[0007] Embodiments described herein can streamline alert
Definition, Detection and Delivery via an Alerts Catalog.
Embodiments described herein can capture Alerts definitions in the
Alerts Catalog exposed via runtime API. The UI design can be
enabled to dynamically build UX with proper eligibility and
widgets. Alert templates can be generated to define subscription
preferences. Customer support can see preference changes and alerts
delivery history in real time. Fraud teams can subscribe to daily
data feeds. IT/OP and engineer teams can decide horizontal
(business domain) or vertical scale (throughput), and monitor
specific operation events (error topics in the Catalog)
[0008] Embodiments described herein enable in-memory event
correlation and computing for real-time detection, based on the
Alerts Catalog, Transaction or fraud events, User subscriptions and
preferences. Embodiments described herein enable in memory
preference policy enforcement for Alerts delivery. This can enable
duplicate detection, suppression, suspension. Embodiments described
herein can define alerts based on (1) subscriptions; (2) event
detections; (3) actions.
[0009] Embodiments described herein integrates in-memory event
detection and the notification mechanism with enterprise data
storage. A customer can connect to the system for transaction
functions (e.g., customer is making a $10,000 deposit) and the data
contained within the transaction can be useful (e.g., $10,000 is a
large deposit event for this customer) and can generate actionable
insight to create differentiating function (e.g., a notification to
the customer for a large account balance or an up-sale offer to the
customer to purchase an investment product, like mutual funds).
[0010] In accordance with an aspect, there is provided a system for
generating alert notifications configured to: load and store data
from a plurality of source systems at a data hub implemented by a
non-transient data store; receive a request for an alert
subscription at the data hub, the request indicating a subscriber
and an alert configurations; generate and store an alert rule
corresponding to the alert configuration, the alert rule having a
trigger and an action; detect an event at the data hub based on
correlated event data of the data stored at the data hub, the
correlated event data corresponding to the trigger of the alert
rule, the correlated event data based on in-memory event
correlation and computing for real-time detection; generate an
alert notification for the alert trigger based on the action of the
alert rule; and transmit the alert notification to the subscriber
based on the subscription.
[0011] In some embodiments, the subscriber is linked to an alert
format and the alert service is configured to generate alert data
using the event data, format the alert data based on the alert
format of the target unit, generate the alert notification based on
the alert data, and generate alert processing result data.
[0012] In some embodiments, the alert notification is assigned an
alert identifier and wherein the processor stores data for the
alert notification and the alert identifier in a history log.
[0013] In some embodiments, the alert notification is assigned an
action identifier based on the action of the alert rule, wherein
the action identifier is a pointer to code for adding the action to
the alert notification.
[0014] In some embodiments, the system has an alert handler
configured to monitor the alert notification for user response and
record the user response in association with the alert
identifier.
[0015] In some embodiments, the system has an alert subscription
service configured to store a mapping between a customer
identifier, customer preferences, and the alert rule, the
subscriber being linked to the customer identifier.
[0016] In some embodiments, the system has an application
programming interface to receive the request for the alert
subscription.
[0017] In some embodiments, the system has an alerts catalogue for
storing the alert rule.
[0018] In some embodiments, the system has an alert template to
define the alert configuration for the alert subscription.
[0019] In some embodiments, the system integrates in-memory event
detection and alert notification with the data hub.
[0020] In accordance with an aspect, there is provided systems,
processes and devices for an information delivery platform or data
hub with an alert processor that can be configured to receive a
request to generate an alert configuration at the data hub, the
request indicating a target unit; generate and store an alert rule
corresponding to the alert configuration, the alert rule having a
trigger and an action; detect an event at the data hub based on a
set of data of the data stored at the data hub, the event having
event data; convert the event data to an alert trigger at the data
hub based on the trigger of the alert rule; generate an alert
notification for the alert trigger based on the action of the alert
rule; and transmit the alert notification to the target unit
[0021] In various further aspects, the disclosure provides
corresponding systems and devices, and logic structures such as
machine-executable coded instruction sets for implementing such
systems, devices, and methods.
[0022] In this respect, before explaining at least one embodiment
in detail, it is to be understood that the embodiments are not
limited in application to the details of construction and to the
arrangements of the components set forth in the following
description or illustrated in the drawings. Also, it is to be
understood that the phraseology and terminology employed herein are
for the purpose of description and should not be regarded as
limiting.
[0023] Many further features and combinations thereof concerning
embodiments described herein will appear to those skilled in the
art following a reading of the instant disclosure.
DESCRIPTION OF THE FIGURES
[0024] In the figures, embodiments are illustrated by way of
example. It is to be expressly understood that the description and
figures are only for the purpose of illustration and as an aid to
understanding.
[0025] Embodiments will now be described, by way of example only,
with reference to the attached figures, wherein in the figures:
[0026] FIG. 1A illustrates a system architecture diagram of a
proprietary Information Delivery Platform (IDP) in accordance with
one embodiment.
[0027] FIG. 1B is a view of components of a data storage and
processing system including IDP.
[0028] FIG. 2 illustrates a schematic diagram of an example
alerting service system, according to some embodiments.
[0029] FIG. 3 illustrates a schematic diagram of an example
alerting service system, according to some embodiments.
[0030] FIG. 4 illustrates a schematic diagram of an example
alerting service, according to some embodiments.
[0031] FIG. 5 illustrates a diagram of example use cases for an
alerting service system, according to some embodiments.
[0032] FIG. 6 illustrates a schematic diagram of an example
alerting service system, according to some embodiments.
[0033] FIG. 7 illustrates a diagram of example use cases for an
alerting service system, according to some embodiments.
[0034] FIG. 8 illustrates a schematic diagram of an example
alerting service system, according to some embodiments.
[0035] FIG. 9 illustrates a schematic diagram of an example
alerting service, according to some embodiments.
[0036] FIG. 10 illustrates a schematic diagram of an example
alerting service system, according to some embodiments.
[0037] FIG. 11 illustrates a schematic diagram of an example
alerting service system, according to some embodiments.
[0038] FIG. 12 illustrates a schematic diagram of an example
alerting service system, according to some embodiments.
[0039] FIG. 13 illustrates a schematic diagram of an example
alerting service system, according to some embodiments.
[0040] FIG. 14 illustrates a schematic diagram of an example
alerting service system, according to some embodiments.
[0041] FIG. 15 illustrates a schematic diagram of an example
alerting service system, according to some embodiments.
[0042] FIG. 16 illustrates a schematic diagram of an example
alerting service system, according to some embodiments.
[0043] FIG. 17 illustrates a schematic diagram of an example
alerting service system, according to some embodiments.
[0044] FIG. 18 illustrates a schematic diagram of an example
alerting service system, according to some embodiments.
[0045] FIG. 19 illustrates a schematic diagram of an example
alerting service system, according to some embodiments.
[0046] FIG. 20 illustrates a schematic diagram of an example
alerting service system, according to some embodiments.
[0047] FIG. 21 illustrates a schematic diagram of an example
alerting service system, according to some embodiments.
[0048] FIG. 22 illustrates a schematic diagram of an example
alerting service system, according to some embodiments.
[0049] FIG. 23 illustrates a schematic diagram of an example
alerting service system, according to some embodiments.
[0050] FIG. 24 illustrates a schematic diagram of an example
alerting service system, according to some embodiments.
[0051] FIG. 25 illustrates a schematic diagram of an example
alerting service system, according to some embodiments.
[0052] FIG. 26 illustrates a schematic diagram of an example
alerting service system, according to some embodiments.
[0053] FIG. 27 illustrates a schematic diagram of an example
architecture for an alert service system, according to some
embodiments.
[0054] FIG. 28 illustrates a schematic diagram of an example
architecture for an alert service system, according to some
embodiments.
[0055] FIG. 29 illustrates a schematic diagram of an example
architecture for an alert service system, according to some
embodiments.
[0056] FIG. 30 illustrates a schematic diagram of an example
interface for an alert service system, according to some
embodiments.
[0057] FIG. 31 illustrates a schematic diagram of an example
interface for an alert service system, according to some
embodiments.
[0058] FIG. 32 illustrates a schematic diagram of an example
interface for an alert service system, according to some
embodiments.
[0059] FIG. 33 illustrates a schematic diagram of an example
alerting service system, according to some embodiments.
[0060] FIG. 34 illustrates a schematic diagram of an example
alerting service system, according to some embodiments.
[0061] FIG. 35 illustrates a schematic diagram of an example
alerting service system, according to some embodiments.
[0062] FIG. 36 illustrates a schematic diagram of an example
architecture for an alerting service system, according to some
embodiments.
[0063] FIG. 37 illustrates a schematic diagram of an example
alerting service system, according to some embodiments.
DETAILED DESCRIPTION
[0064] Embodiments of methods, systems, and apparatus are described
through reference to the drawings.
[0065] The following discussion provides many example embodiments
of the inventive subject matter. Although each embodiment
represents a single combination of inventive elements, the
inventive subject matter is considered to include all possible
combinations of the disclosed elements. Thus if one embodiment
comprises elements A, B, and C, and a second embodiment comprises
elements B and D, then the inventive subject matter is also
considered to include other remaining combinations of A, B, C, or
D, even if not explicitly disclosed.
[0066] The embodiments of the devices, systems and methods
described herein may be implemented in a combination of both
hardware and software. These embodiments may be implemented on
programmable computers, each computer including at least one
processor, a data storage system (including volatile memory or
non-volatile memory or other data storage elements or a combination
thereof), and at least one communication interface.
[0067] Within an enterprise data warehouse, there may be large
volumes of data being ingested and stored; computational demands
may also be high for extracting, transforming or otherwise
processing the volumes of data into end target databases or end
appliances. With traditional ETL techniques, there exists a number
of pain points: "data silos", which refer to data that is under
control of one group or application and isolated from the rest of
the organization may be common, and there may be need for
replication of large volumes of data between the various
appliances. In addition, computing and storage capacity are
inherently coupled, and cannot be independently scaled. Data access
control and security may be negatively affected.
[0068] The financial cost of data aggregation and consumption with
current technology may be high, and meeting demand may become
increasingly technically challenging.
[0069] Network bandwidth may also become a significant constraint
for data communication between an enterprise data system and
external systems, as well as in/out of the landing zone for batch
data transmission for the enterprise data system.
[0070] In addition, capturing and maintaining accurate data lineage
may also be challenging under the traditional approach.
[0071] There may be no "balance and control" or enterprise-level
reconciliation patterns or models for data stored within a
traditional enterprise data system. This may be the case if the
enterprise data system serves as a book-of-reference and not a
book-of-record. However, there is growing need for enterprise
reconciliation or balance and control capabilities and
patterns.
[0072] Improving ease of understanding of the data glossary and
relationship between data/sources is needed to support self-serve
data science initiatives.
[0073] The Financial Services Industry is a data driven industry.
The scope, quality, cost, performance and freshness of data that
has been "good enough" in the past is no longer good enough. Many
critical bank processes may need low cost, easy to access, reliable
and consistent data. These process include but are not limited to:
Anti Money Laundering Compliance, Regulatory and Compliance
Reporting, Risk Management, Customer Insights, Sales Performance
Management and Channel Optimization.
[0074] While the bank has multiple "point to point" and shared data
acquisition and management platforms in place, none of these
platforms are currently fully meeting modern bank's needs for data
reliability, flexibility, low cost and performance.
[0075] The Information Delivery Platform described in the
embodiments herein incorporates new technology, a new operating
model that optimizes the accountabilities for data quality and a
simplified approach to information management. This platform may
provide information management capability to meet the rapidly
increasing demand for low cost, easy to access, reliable and
consistent data.
[0076] Referring now to FIG. 1A, which illustrates a system
architecture diagram of an example Information Delivery Platform
(IDP) 2100 with Channels 2300, Product Systems 2400a, Corporate
Systems 2400b and T&O (Technology and Operation) Systems
2400c.
[0077] In an example embodiment, IDP 2100 is a data aggregation,
processing, and analytics environment, combining multiple sources
of data into a single organization-wide repository, and providing
fast and cost-effective access to data.
[0078] In the present application, as an example, the organization
is a bank. However, it should be appreciated that the organization
can be any type of organization or company that may need storage
and processing of data for daily operations. For example, the
organization can be a government entity, a law firm, a school, a
store, or a restaurant, and so on.
[0079] IDP 2100 can provide more data in less time. IDP 2100 can
provide users with a high performance platform for processing
queries. IDP 2100 can provide built in data quality management,
high availability and disaster recovery. IDP 2100 can have an
innovative operating model provides subscriber businesses a direct
CIO accountability to ensure their specific needs are met. IDP 2100
can provide the opportunity to eliminate data sprawl by eliminating
the motivations to create redundant and overlapping data marts. IDP
2100 can provide the following benefits: CIO accountability model
means conversations about sourcing data, its content and it's
quality take place directly between the owners of the source
systems and the consumers of the data; high performance, cost
efficient staging platform means improved query performance and
lower costs for accumulating low level detail data; data quality
management means problems in the source data are identified early
and actively managed; consumer driven data model means the
integrated database structures are presented in simple, business
friendly terminology; and provides for self-serve data usage.
[0080] IDP 2100 is a shared information management component of the
Analytical/Data Hub that can provision well managed data to meet
multiple reporting and analytical requirements quickly and
efficiently. IDP 2100 can provide an innovative operating model
that leverages the strengths of all stakeholders and eliminates
unnecessary hand offs. It is built from the ground up to meet the
requirements of regulators and business process that demand
on-going demonstration of data quality management and proof that
the data is an accurate and complete representation of reality. It
presents data to the business community using industry and bank
terminology. It will provide the opportunity to eliminate data
sprawl by eliminating the motivations to create redundant and
overlapping data marts. It may provide robust, highly resilient
infrastructure, DR (Disaster Recovery), high performance as most
queries and loads run in a fraction of the time of existing
platforms, easy tracking of data assets under management, data
stewardship and data governance, data quality management and
reporting capability, and data in cross application integrated (L2)
model.
[0081] In one example embodiment, central data hub 3000 includes
IDP 2100. In one embodiment, the IDP 2100 may include a scalable
data store (also referred to as a "data lake"), which may collect
and store massive amounts of data for long periods of time. The
data stored may be structured, semi-structured, unstructured, or
time-sensitive data (e.g. events, etc.). A central aggregation and
distribution point ("book of reference") may be generated for all
book-of-record data within the bank, which provides consistent and
efficient access to reference data. Both raw and processed data
within the data lake may be available for consumption; powering
analytics; machine learning; consumer-specific data accessible via
batch, SQL, streaming, native Hadoop APIs. Linear scalability of
data is also provided.
[0082] In some embodiments, IDP 2100 is connected to channel
services 2300 through connector grid 2110a and connected to product
systems 2400a, corporate systems 2400b and T&O systems 2400c
through connector grids 2110b and 2110c.
[0083] Channel services 2300 may include internal or external
interfaces adapted for different service groups, such as
Point-of-Sale (POS) terminals, watch interfaces, mobile devices,
tablet devices, online portals, ATMs, branches, call centers, sales
forces, and so on. Each of these service group may receive and
utilize data from IDP 2100 through connector grid 2110a. Each
channel may have a user interface designed to display various data
and information and to receive user inputs.
[0084] Across channels 2300, customer information is captured
consistently at all points of collection for all LOBs and channels,
aligned to standards defined for the Enterprise Customer Domain. A
single view of customer information and aggregate view of customer
holdings can be displayed on channels, in real-time or near
real-time, and on demand if necessary.
[0085] In addition, product systems 2400a, corporate systems 2400b
and T&O systems 2400c may also receive and utilize data from
IDP 2100 through connector grids 2110b, 2110c.
[0086] IDP 2100 may receive raw data from a variety of data
sources. Data sources include, among others: [0087] Book of record
transaction systems (BORTS) [0088] Clickstreams (web-logs) [0089]
Social media [0090] Server/machine logs [0091] Unstructured data
[0092] Real-time event streams
[0093] Raw data may be received and stored into a staging area. The
staging area may be part of a "data lake" foundation from which
groups across the organization can draw needed data. This staging
area may be also referred to as "level 0 (L0)" data storage.
[0094] For example, when the organization is a bank, different
groups may utilize data from the data lake. The groups may include:
AML (Anti-Money Laundering), regulatory organizations or protocols,
industry associations, U.S. Heightened Standards, Enterprise Wre
Payments, LOB (Line of Business) Scorecards, Corporate Audit
Analytics, Fraud/Criminal Risk Investigation, Legacy Data Marts
Simplification.
[0095] IDP 2100 may be the foundation for the overarching data
environment, combining multiple sources or book of record
transaction systems (BORTS) into a single organization-wide
repository and provides fast and cost-effective access to both raw
and conformed data.
[0096] FIG. 1B is a view of components of a data storage and
processing system. The system includes an integration component,
data and analytics component, and enterprise foundational
components. The integration component has a connector grid. The
connector grid provides enterprise API services with standard
interfaces to communicate with applications and external systems.
The data and analytics component has a consolidated Book of Record
Data (BORT) and advanced analytics with machine learning.
[0097] The enterprise foundational components include CIAM for
identity and credential management. CIAM enables single-sign on for
data access with authentication and authorization. The enterprise
foundational components include Master Data Management components
ECIF, RDM, and EPM to provide a 360 degrees, holistic customer view
of data. The Master Data Management components have an enterprise
product catalog. The Master Data Management components provide a
single source of reference data. The enterprise foundational
components include digitization and business process management for
digitization and document management with smart robotics.
[0098] Example embodiments of an alert service system is described.
In some embodiments, the alert service system is interconnected
with IDP 2100. The IDP 2100, in some embodiments, is configured to
include Bank Enterprise Architecture, Technical Architecture, and
Enterprise Alert Service. IDP 2100 integrates an alert service to
provide in-memory event detection and the notification mechanism.
Since users are able to connect for transaction functions (e.g.,
customer is making a $10,000 deposit), the information contains
within the transaction is useful (e.g., $10,000 is a large deposit
event for this customer) for the alert service and can generate
actionable insight to create differentiating function (e.g., a
notification to the customer for a large account balance or another
action).
[0099] Embodiments described herein generate alerts for
customers/users who have a subscription to receive such alerts
based on a set of defined events. Functions can be exposed via
APIs.
[0100] Embodiments described herein can streamline alert
Definition, Detection and Delivery via an Alerts Catalog.
Embodiments described herein can capture Alerts definitions in the
Alerts Catalog exposed via runtime API. The UI design can be
enabled to dynamically build UX with proper eligibility and
widgets. Alert templates can be generated to define subscription
preferences. Customer support can see preference changes and alerts
delivery history in real time. Fraud teams can subscribe to daily
data feeds. IT/OP and engineer teams can decide horizontal
(business domain) or vertical scale (throughput), and monitor
specific operation events (error topics in the Catalog)
[0101] Embodiments described herein can provide in memory event
correlation and computing for real-time detection, based on Alerts
Catalog, Transaction or fraud events, User subscriptions and
preferences. Embodiments described herein can provide in memory
preference policy enforcement for Alerts delivery to duplicate
detection, suppression, and suspension.
[0102] Embodiments described herein can define alerts using
subscriptions, event detections and actions.
[0103] Embodiments described herein enable in-memory event
correlation and computing for real-time detection, based on the
Alerts Catalog, Transaction or fraud events, User subscriptions and
preferences. Embodiments described herein enable in memory
preference policy enforcement for Alerts delivery. This can enable
duplicate detection, suppression, suspension. Embodiments described
herein can define alerts based on (1) subscriptions; (2) event
detections; (3) actions.
[0104] Embodiments described herein integrates in-memory event
detection and the notification mechanism with enterprise data
storage. A customer can connect to the system for transaction
functions (e.g., customer is making a $10,000 deposit) and the data
contained within the transaction can be useful (e.g., $10,000 is a
large deposit event for this customer) and can generate actionable
insight to create differentiating function (e.g., a notification to
the customer for a large account balance or an up-sale offer to the
customer to purchase an investment product, like mutual funds).
[0105] In accordance with an aspect, there is provided a system for
generating alert notifications configured to: load and store data
from a plurality of source systems at a data hub implemented by a
non-transient data store; receive a request for an alert
subscription at the data hub, the request indicating a subscriber
and an alert configurations; generate and store an alert rule
corresponding to the alert configuration, the alert rule having a
trigger and an action; detect an event at the data hub based on
correlated event data of the data stored at the data hub, the
correlated event data corresponding to the trigger of the alert
rule, the correlated event data based on in-memory event
correlation and computing for real-time detection; generate an
alert notification for the alert trigger based on the action of the
alert rule; and transmit the alert notification to the subscriber
based on the subscription.
[0106] In some embodiments, the subscriber is linked to an alert
format and the alert service is configured to generate alert data
using the event data, format the alert data based on the alert
format of the target unit, generate the alert notification based on
the alert data, and generate alert processing result data.
[0107] In some embodiments, the alert notification is assigned an
alert identifier and wherein the processor stores data for the
alert notification and the alert identifier in a history log.
[0108] In some embodiments, the alert notification is assigned an
action identifier based on the action of the alert rule, wherein
the action identifier is a pointer to code for adding the action to
the alert notification.
[0109] In some embodiments, the system has an alert handler
configured to monitor the alert notification for user response and
record the user response in association with the alert
identifier.
[0110] In some embodiments, the system has an alert subscription
service configured to store a mapping between a customer
identifier, customer preferences, and the alert rule, the
subscriber being linked to the customer identifier.
[0111] In some embodiments, the system has an application
programming interface to receive the request for the alert
subscription.
[0112] In some embodiments, the system has an alerts catalogue for
storing the alert rule.
[0113] In some embodiments, the system has an alert template to
define the alert configuration for the alert subscription.
[0114] In some embodiments, the system integrates in-memory event
detection and alert notification with the data hub.
[0115] Embodiments described herein generate alerts (e.g., SMS or
email notification) to customers/users who have a subscription such
alerts (e.g., defined the interest/subscription in the Mobile
Banking Application) based on a set of defined events (e.g., when
my chequing account balance is less than $100). The alert
definition, detection and delivery is integrated with data storage
to provide an in-memory solution. This can enable efficient event
detection.
[0116] FIG. 2 depicts an example Bank Technical Architecture (TA)
for an example Alert Service. The Alert Service includes
connectivity with sources, formatting and delivery agents, and
targets. The Alert service can use MDM and a template repository
unit.
[0117] The Alert Service can provide a reliable, scalable shared
service for delivering outbound communications ("alerts") to
customers.
[0118] The "Alerts" Taxonomy and Canonical Model can provide an
Enterprise-wide taxonomy and canonical model for "alerts"--that is,
alerts, notifications and offers. Alert Subscription can allow
customers to create alert subscriptions or configurations that can
trigger alert notifications. "Alert" Formatting and Delivery can
enable processing, formatting and delivery of alert notifications
(alerts, offers, notifications) to alert targets.
[0119] The example Alert Service can use the following style and
patterns at a logical level of each of the following example
components.
TABLE-US-00001 Style/Pattern Name Level Where Used Online
transaction processing Logical Alerts Detection Service
(OLTP)/Request-Reply Direct Alert Source Canonical Data Model
Logical Alerts Batch/Batch to OLTP Logical Batch Alert Source
Scatter-Gather Logical Alert Subscription Service OLTP/Content
Enricher Logical Alert Service - Prioritization and Enrichment
OLTP/Service Grid Logical Alert Subscription Service - Caching with
Service Grid
[0120] In some embodiments, the Alert Service can implement a
"pull-based" approach, where the Alert Service can be rolled out
incrementally, with capabilities being added as/when requested by
projects of an organization by way of incremental alert
configurations.
[0121] Example use cases for the Alert Service are Enterprise Wre
Payments and electronic statement or eStatement notifications.
[0122] An example alert system can have a number of features
including providing duplicate capabilities (including for mobile
solutions for banking, payment, and credit; SMS; messaging
services; online banking solutions; custom alerts "engines");
scattering of customer preferences and alert subscriptions (e.g.
multiple preference and alert subscriptions stores, inconsistencies
and widely differing capabilities across applications and lines of
businesses); no "single view" of customer communications; support
for different types of "targets" (SMS, email, etc.); adding new
"alerts"; implementation across lines of businesses; and reuse or
sharing capabilities.
[0123] In some embodiments, the alert system is provided at an
enterprise level, ingesting large amounts of data from a wide
variety of sources, including different lines of businesses within
the enterprise. In some embodiments, the alert system streamlines
the lifecycle for implementing requirements to provide alert
services to a variety of different contextual environments
acceptable to a variety of systems, applications, or appliances,
for example, specific to different lines of businesses of an
enterprise. Each line of business may interconnect with systems or
applications that are best suited to receive certain kinds of data
or data in specific formats, for example. In some embodiments, the
alert system integrates different vendor offerings, providing
functionality to these different systems, for example, without
requiring the duplication of resources, data, or computer services.
As it may be otherwise unfeasible to provide a single alert system,
including alert service, across an enterprise, the alert system, in
some embodiments, may address this and avoid the need for hard
coding or duplicating various features of the alert service in
different systems within an enterprise.
[0124] For example, in some embodiments, the alert system includes
an alert catalogue that provides definitions of alerts, for
example, data attributes, flags, and other structures that enable a
computer system to use and process the alerts, including initiating
notifications upon occurrence of certain events (e.g. automatically
using a listener) and/or based on other data (e.g. using handlers).
In some embodiments, an alert definition includes a trigger and an
action.
[0125] In some embodiments, the alert system is configured to call
the alert catalogue and dynamically render a visual interface
element accessible to a user. Examples of an alert definition
registered through the catalogue may be to send a notification to a
certain individual if a price is lower than $10.
[0126] A user can engage with a user unit included in the alert
system to subscribe to various alerts and/or provide input that
will be used by the alert system to generate and register a new
definition in the alert catalogue. A user can make changes to
various features, including alert definitions. In some embodiments,
the alert system provides a dynamic user interface that populates
interface elements to provide a user-friendly view or perspective
of the catalogue.
[0127] In some embodiments, the alert system is configured to
provide delivery of alerts to all the users in the enterprise who
are subscribed to the alert. Delivery of each instance of the
alert, including its content, may be based on data associated with
the individual receiving the alert. For example, for the same
alert, different users may receive different personalized
messages.
[0128] In some embodiments, an alert catalogue is configured to
register all dynamic data elements. The dynamic data elements can
be configured by data in an alert template, for example. Alerts may
be managed using a queue system, based on various times of time
indicators.
[0129] In some embodiments, data related to or stored by the alert
system, for example, data in the alert catalogue and meta data
related to its use and updates, is provided to users, for example,
on request by an analytical team. In some embodiments, a machine
learning unit, for example, included in the IDP or interconnected
with the IDP, is configured to receive the data.
[0130] In some embodiments, channels interconnected with the alert
system are configured to dynamically call functions defined in an
API to dynamically render a user experience and generate
subscriptions so that a user can make changes to alert definitions,
for example. At runtime, in some embodiments, a catalogue entry or
definition is loaded into an alert engine, for example, to generate
alerts when the definition criteria are met. In some embodiments,
new alerts are defined (e.g. using a template or rules) and this
may not require changes to the alert engine or application code,
and customer preferences and contextual data are automatically
captured and stored.
[0131] A dynamic user interface is provided to allow subscriptions
to be managed. In some embodiments, elements within the user
interface allow presentation and modification of alerts or alert
data affecting enterprise-wide subscriptions. In this way, the
alert system is configured to provide a centralized alert
management system that avoids or reduces the duplication of large
amounts of data or the need for separate alert services that are
individually tailored to the specific contextual environments of
different computer systems or lines of businesses.
[0132] In some embodiments, the alert system maintains
alert-related data, including alerts, alerts generated,
notifications sent, and other data. This data can be used by a
fraud team to categorize for different purposes.
[0133] In some embodiments, the alert system or alert engine is
configured with an adaptive or dynamic mechanism to provide
additional security and reliability control, for example, based on
the type of message and type of channel (for example, through which
the message is sent to a user). In some embodiments, the alert
system includes an adaptive mechanism to add controls relating to
security.
[0134] In some embodiments, the alert system is configured to
detect duplicate or similar alerts as well as duplicate
deliverables to the same location, address, or user, for example,
those alerts defined in the alert catalogue or received by
different users or systems updating the alert system.
[0135] In some embodiments, the alert system is configured to
handle (e.g. generate, receive, deliver, and/or store an associate
definition in an alert catalogue) actionable alerts, for example, a
two-way SMS or other asynchronous data exchanges. For example, the
alert system is configured to detect such exchanges or data
associated with such exchanges and manage actionable alerts from
different requesters (e.g. an enterprise fraud alert). In some
embodiments, the alert system is configured to implement complex
event processing and timing, as well as tracking of the original
source of an SMS, for example. For example, in the context of an
external service providing an electronic wallet or electronic pay
capabilities, the alert system is configured to generate alerts and
trigger specific deliveries depending on the nature of the alert.
As an example, the alert system can be configured to inform a user
when their email changes or their credit card is rejected in
relation to their electronic wallet service.
[0136] In some embodiments, the alert service is configured to
provide APIs that can be used by different channel services, mobile
applications, support applications, and other computer systems with
different environments and technical requirements. This allows a
single alert service to provide complex functionality across an
entire enterprise, including different lines of business and
services with different needs within that enterprise. This can
provide a highly scalable system with capability to process a high
number of transactions. Horizontal scalability can be provided to
support different types of transactions and vertical scalability
can be provided to interoperate with different applications and
channels.
[0137] In some embodiments, businesses directly contribute to
alerts definitions for both functional and non-functional
requirements. The information can be captured in an alerts catalog,
which is exposed via a runtime API. The alert service can include a
user interface unit, which is configured to provide a user
interface design that is enabled to dynamically build a user
experience with proper eligibility and widgets. The business may
engage with the user interface unit to construct alerts templates.
Other users, for example, administrators or customer support teams,
can access and view preference changes and alert delivery histories
in real time via the user interface unit. For example, a fraud team
may subscribe to a daily alert data feed via the IDP. As another
example, an IT or engineer team can engage with the alert system to
configure horizontal (e.g. business domain) or vertical (e.g.
throughput) scale of the alert system, for example, configure which
systems, lines of businesses, and amount of data that can engage
with the alert system, as well as monitor specific operation events
(e.g. errors).
[0138] In some embodiments, the alert system provides a streamlined
alert definition, detection, and delivery via an alert catalogue.
In some embodiments, the alert system provides determination and
storage (e.g. transient storage) of event correlation data and
computing for real time detection based on, for example, alert
catalogue data, transaction or fraud events, and/or user
subscriptions and preferences. In some embodiments, the alert
system provides storage (e.g. transient storage) of preference
policy enforcement data for alerts delivery. This may include
functionality for detection of duplicates, suppression, and
suspension.
[0139] In some embodiments, the alert system is configured to
provide publication of actionable alert events, for example,
including two-way asynchronous SMS message correlation
capabilities. In some embodiments, alert system is configured to
detect alert delivery errors or failures, including, for example,
detection of emails that could not be delivered (e.g. bounced
emails).
[0140] In some embodiments, the alert system is configured to
enable its functionalities and capabilities via APIs. For example,
APIs allow for the alert system functions to be exposed to
different services, channels, applications, appliances, and
systems.
[0141] FIG. 3 is a schematic diagram of an example architecture for
Alert Subscriptions in an example Alert Service, according to an
alert system. As depicted, customer preferences, alert
subscriptions, and target definitions are provided to each of
different services in separate processes from separate data
stores.
[0142] FIG. 4 is a schematic diagram of an example architecture for
Formatting and Delivery in an example Alert Service, according to
an alert system. As depicted, transmission of data between
different formatting and delivery units and different target
devices or units is separate.
[0143] A summary of example capabilities for an alert service
system is as follows:
TABLE-US-00002 Functions Current Associated Executed by Application
Application Efficiencies in Processes Application Application
Redundancy Dependencies Application Format Online Format alert
Duplicate N/A Formatting "alerts" banking, "messages" "formatting"
managed within payment, and using capabilities each credit
application- exist across application. services; provided LOBs/
financial templates applications. platforms and styles. Deliver
Online Deliver alerts Duplicate N/A Delivery "alerts" banking, to
"targets" "delivery" managed within payment, and supported by
capabilities each credit individual exist across application.
services; application LOBs/ financial using applications. platforms
application- specific mechanisms. Manage Online Allow None N/A
Entitlements Entitlements banking, management managed within
payment, and of alert OLBB credit services entitlements Manage
alert Online Allow Distinct "alert N/A Alert subscriptions banking,
customers to subscription Subscriptions payment, and "subscribe"
and managed within credit for alerts and preferences" each
services; specify the stores exist application. financial target/s
to across LOBs/ Clairmail: Alert platforms which a given
applications. Subscriptions alert must be stored outside sent. of
FI and Clairmail becomes a bottleneck when adding new alert types.
Alert Online Alerts are Similar alert N/A Alert processing
"Processing" banking, received from "processing is performed
payment, and alert sources, logic" exists within each credit
stored, in multiple application. services; scheduled for
applications. financial delivery and platforms then delivered.
Operations Online Operations None N/A view banking staff can view
services alerts, see alert status (delivered/ failed, etc.) and (?)
resend failed alerts.
[0144] An example alert service system is configured to provide a
number of features, including an improved experience for customers
(e.g. flexible ("I can create alerts for things I care about . . .
"), consistent ("Let me set my preferences easily, in one place"),
easy to use ("This is so easy to use"), reliable); shared
capabilities and reuse of components (e.g. reduce costs by enabling
enterprise-wide reuse, provide the capabilities and reliability
needed by each LOB); and agility (e.g. enable incremental migration
from an architectural state (e.g. as described above in relation to
an alert system with some drawbacks) to a further improved
architectural state; and fit in with existing systems and
infrastructure of an organization.
[0145] FIG. 5 is a schematic diagram of example features of some
embodiments of an alert services system. As depicted, the alert
services system provides alerts and offers based on customer
preferences, offers that are relevant to the customer, channel
integration with customer-facing channels, and tracking or history
keeping. This can provide an improved customer experience, cost
reduction, cross selling opportunities, fraud reduction, direct fee
revenue, for example, where a customer is willing to pay a fee for
an alert, and improved customer engagement.
[0146] An example alert delivery service system is configured to
provide enterprise-wide "alerts" taxonomy, using a canonical model
(e.g. both fire-and-forget and actionable "alerts" (notifications,
alerts, offers)); service of multiple "targets" (e.g. SMS, email,
message-box, fax, UIC, etc.), including secure delivery (where
applicable); scalable, reliable, high performance architecture;
delivery confirmation (where possible); an ability to notify alert
sources upon alert delivery, failure, etc. (e.g. to support
billing); communication history (record of previously sent alerts);
an easy migration path for existing systems; and support for
federated formatting and delivery.
[0147] FIG. 6 is a schematic diagram of example Business
Capabilities and corresponding units in the underlying architecture
of an example alert services system. As depicted, the alert
services system includes a number of channels and units, such as
marketing units, sales units, origination and fulfillment units,
servicing units, customer information management units, channel
experience units, and channel management units.
[0148] FIG. 7 is a schematic diagram of an example alert taxonomy
of an alert services system. As depicted, the system can provision
alerts, notifications, and targeted offers, based on events. These
can be provided using architecture described or corresponding
logical units.
[0149] FIG. 8 is a schematic diagram of an example architecture of
an alert services system. As depicted, the architecture can
implement sources to produce business events and utilize CEP on the
Hub to convert events into alerts. The architecture can also
provide that Batch-to-OLTP be performed outside of the Hub or
within the Hub. Legacy systems and non-Hub-based implementations
can directly produce alerts.
[0150] There may be 3 types of Alert Sources in an example alert
service system: [0151] 1) Alert Detection (CEP, say) [0152] 2)
batch process into a real-time based process or transaction [0153]
3) "Direct" Alert producers
[0154] Sources can be internal or external to the organization
system e.g. bank. Product systems and channels (e.g. MECH, NCCS,
OLBB) can generate both business events, batch files, etc., while
Applications (e.g. RIS) may generate alerts directly).
[0155] FIG. 9 is a schematic diagram of an example architecture for
an alert services system that provides management of Alert
Subscriptions. As depicted, an alert subscription service can
interface with a customer or employee/administrator as well as with
an MDM unit, which can store all customer preferences, alert
subscriptions, and target definitions.
[0156] FIG. 10 is a schematic diagram of an example architecture
for an alert subscription service. As depicted, the system can
determine Alert Subscriptions at Runtime. The alert subscription
service is configured to communicate with an alert detection unit,
for example, involving a cache. The alert subscription service is
configured to provide batch files to OLTP and to provide direct
alerts to a direct alerts unit.
[0157] FIG. 11 is a schematic diagram of an example architecture
implementing Pipeline, Formatting, and Delivery units for an alert
services system. As depicted, a Hub can include an alert service,
which can include a processing pipeline unit and a formatting and
delivery unit. The alert service is configured to connect with a
formatting and delivery agents unit, MDM unit, template repository,
and CRM. The alert service can include an alert store as well as an
alert scheduler; both units can transmit and receive data to the
processing pipeline unit or any subcomponent. The processing
pipeline unit is configured to provide various outputs and data,
including error messages and outputs, as well as receive various
inputs such as alert data.
[0158] FIG. 12 is a schematic diagram of an example architecture of
an alert services unit providing Hub-based Mediation to Formatting
and Delivery Agents. As depicted, the alert services unit is
configured to provide formatting and delivery outputs to a
formatting and delivery agents unit using hub-based adapters or
mediations. The alert services unit can also be configured to use a
non-hub-based adapter implementing a formatting and delivery
interface in some cases, for example, where a hub-based adapter is
not possible.
[0159] FIG. 13 is a schematic diagram of an example process of
Delivery Reporting by an alert services unit. At 1, alert data is
provided to an alert service unit. At 2, data is exchanged between
an alert store and a processing pipeline unit included in the alert
service unit. At 3, a formatted alert is provided to a formatting
and delivery unit, including a formatting and delivery agent. At 4,
a formatted alert is provided to a target unit, for example, a
mobile phone of a customer. At 5, data is provided from the
formatting and delivery agent to a formatting and delivery unit
included in an alert service unit included in a hub. At 6, the
formatting and delivery unit exchanges data with a data store. At
7, the alert services unit transmits alert processing results
(events) data.
[0160] Example pseudocode in an example process for implementing
actionable alerts in an alert services system follows.
[0161] An Alert Source generates an offer ("alert"), containing two
"actions":
TABLE-US-00003 <alert>
<type>SomeOrOtherOffer</type> <actions>
<action id="accept"
url="http://somemarketingsystem.bank.com/accept.jsp?offerid
=abc123d4"/> <action id="reject"
url="http://somemarketingsystem.bank.com/reject.jsp?offerid=abc123d4"/>
</actions> </alert>
[0162] The alert is sent to the Alert Service, which assigns it a
UUID (d58ba2b2daf38f51f5, say). The Alert Service stores the
original action URLs, keyed using the alert ID and an action ID,
say. E.g. "accept"=1, "reject"=2.
TABLE-US-00004 d58ba2b2daf38f51f5, 1 ("accept")
http://somemarketingsystem.bank.com/accept.jsp?offerid=abc123d4
d58ba2b2daf38f51f5, 2 ("reject")
http://somemarketingsystem.bank.com/reject.jsp?offerid=abc123d4
[0163] The alert can be enriched by the Alert Service, which
rewrites the action URLs as follows:
TABLE-US-00005 <alert>
<type>SomeOrOtherOffer</type> ... (other data added by
enrichment from profile, etc.) <actions> <action
id="accept"
url="http://events.bank.com/handle.jsp?id=d58ba2b2daf38f51f5_1"/>
<action id="reject"
url="http://events.bank.com/handle.jsp?id=d58ba2b2daf38f51f5_2"/>
</actions> </alert>
[0164] When a URL is clicked, Alert Service's Action Handler (e.g.
a web-application) can receive the a notification of a "click",
extracts alert ID, action ID, records the customer's response, and
redirects to the original URL (as stored in the enriched
alert).
[0165] FIG. 14 is a schematic diagram of an example architecture
for an alert services system for providing Operational Support. As
depicted, the Alert Services is included as part of a Hub
architecture and itself includes a processing pipeline unit and a
formatting and delivery unit, each of which are configured to
exchange data with an alert store. The alert store is configured to
exchange data with an operations GUI unit, which is configured to
exchange data with an alert warehouse as well as operations units
that can be used by operations staff. The operations GUI unit, for
example, provisions GUI interface elements viewable in an
operations view arrangement, where operations staff can view and
interact with alerts, history, status, routing, and resubmissions
for failed alerts, etc.
[0166] FIG. 15 is a schematic diagram of an example architecture
for an alert services system. The alert services system includes
source units, a hub (including an alert service unit), formatting
and delivery agents and units, and targets. These units can
interact with each other, exchanging data, as depicted.
[0167] FIG. 16 is a schematic diagram of an example architecture
for an alert services system illustrating an example problem in a
Migration: Alert Subscriptions context. The alert services system
can include the depicted customer preferences and alert
subscriptions stores corresponding to different customers.
[0168] FIG. 17 is a schematic diagram of an example architecture
for an alert services system illustrating an example Alert
Subscriptions Migration architecture implementing another example
"Scatter-Gather" architecture. As depicted, as an example, retail
investment service (RIS) alert subscriptions and customer
preferences data is migrated from a storage unit at a customer
preferences and alert subscriptions store into MDM. RIS can now use
the alert subscription service to determine whether to send alerts
or not (and where to send them to) instead of using its own
internal logic.
[0169] FIG. 18 is a schematic diagram of a use case of an example
alert services system. As depicted, the alert services system is
configured to provide eStatement Notifications. At 1, product
systems can provide batch data to a financial institution (FI)
unit, for example. At 2, the FI unit is configured to provide paper
statements. At 3, the FI unit is configured to provide eStatements
(e.g. PDFs). At 4, the FI unit is configured to provide batch
results to OLTP. At 5, an alert service unit within a Hub is
configured to provide an alert to a formatting and delivery unit.
At 6, the formatting and delivery unit is configured to provide
data to a target. At 7, a customer unit is configured to provide
data to a browser.
[0170] FIG. 19 is a schematic diagram of an example phased rollout
of an Alert Service.
[0171] FIG. 20 is a schematic diagram of an example phased rollout
of an Alert Service.
[0172] FIG. 21 is a schematic diagram of an example phased rollout
of an Alert Service.
[0173] FIG. 22 is a schematic diagram of an example phased rollout
of a Formatting and Delivery service.
[0174] FIG. 23 is a schematic diagram of another example phased
rollout of a Formatting and Delivery service.
[0175] FIG. 24 is a schematic diagram of an example maintenance
process in an alert service system, specifically, adding a new
Alert Type.
[0176] FIG. 25 is a schematic diagram of a use case of an example
alert service system, integrated with an online banking for
business unit (OLBB). At 1, an initiator unit transmits an
initiation to an OLBB unit. At 2, the OLBB unit transmits data to
an alert logic unit. At 3, the OLBB unit sends data to an alert
delivery unit. At 4, the alert delivery unit sends a notification
to an approver unit. At 5, the approver unit transmits approval
data to the OLBB unit. At 6, the OLBB unit transmits data to
backend connectors.
[0177] FIG. 26 is a schematic diagram of a use case of an alert
service system, OLBB Migration. At 1, an initiator unit transmits
an initiation to an OLBB unit. At 2, the OLBB unit transmits data
to an alert subscription service unit included as part of a Hub. At
2A, the alert subscription service unit transmits data to an alert
logic unit. At 3, the OLBB unit transmits data to an Alert Service
unit included in a second Hub. At 3A, the alert Service unit
transmits data to an alert delivery unit. At 4, the alert delivery
unit transmits a notification to an approver unit, which transmits
data, at 5, to the OLBB unit. At 6, the OLBB unit transmits data to
backend connectors.
[0178] Alert Delivery Service can provide a uniform enterprise-wide
"alerts" (outbound, electronic customer-communication) Management
and Delivery Framework; provide an LOB-agnostic mechanism for
delivery of outbound electronic messages to customers (and
employees); enable delivery of "alerts" (notifications, offers and
alerts) to multiple target types (such as SMS, email, fax, etc.)
and support the addition of both new "alert" types as well as new
target types (e.g. OLB Message Box, etc.); specify an
enterprise-wide "alerts" taxonomy and canonical model; provide an
easy migration path for existing systems, allowing current
technology investments to be leveraged and migrated over time
towards a shared-services model; enable customers to manage
communication preferences and "alert subscriptions" in a unified
and coherent manner; provide a platform to enable reuse and
cross-LOB sharing and enable technical agility (that is, allow
technology investments to be rationalized incrementally and with
minimal "lock in"); and align with the bank's (or other
organization) enterprise architecture standards and patterns.
[0179] FIG. 27 is a schematic diagram of an example architecture
for an Alert Delivery Service. As depicted, this architecture
includes an Alerts Taxonomy Unit, Alert Delivery Service Unit,
Formatting and Delivery Agent, Alert Detection unit, Runtime
Template Repository, and Customer Communication Preferences
Unit.
[0180] The Alerts Taxonomy is a "catalog" (Excel, Word, etc.)
defining the various "alerts" that the Alert Delivery Service (ADS)
that can be sent via the ADS. Each entry in the catalog specifies
the alert type (e.g. SignficantDepositAlert) along with key-value
pairs that provide actual alert content.
[0181] The Alert Delivery Service Unit is the core CG-based
web-service that accepts alert "messages" and arranges for their
actual delivery to customers, based on customer preferences.
[0182] The Formatting and Delivery Agent is an agent/system (e.g.
in some embodiments, represented internally within CG via a
proxy/adapter) that is capable of (optionally) formatting &
delivering "alert" messages to customers.
[0183] The Alert Detection Unit provides a Hub-based
complex-event-processing (CEP) capability that "monitors" incoming
business events and generates appropriate "alerts" should they be
warranted.
[0184] The Runtime Template Repository allows in cases where the
ADS is configured to "format" alert messages (that is, create a
human-readable message from an XML alert payload), for the ADS to
use simple business-defined templates stored in a "runtime template
repository" to create the human-readable messages.
[0185] The Customer Communication Preferences Unit stores or
manages Customer preferences, as well as "subscriptions"
(indicating the desire to be alerted when certain conditions are
met, such as low account balance, etc.) stored in local alert
engine data repository but soft linked to the ECIF customer
profile.
[0186] FIG. 28 is a schematic diagram of example components and
development ownership for Alerts.
[0187] FIG. 29 is a schematic diagram of alert "SDLC" components
for an Alert Delivery Service.
[0188] FIG. 30 is a schematic diagram of an example UI mockup
(alert admin) for an Alert Delivery Service. As depicted, various
interface elements can be arranged to improve and enable
functionality and engagement.
[0189] FIG. 31 is a schematic diagram of an example UI mockup
(alert subscription) for an Alert Delivery Service. As depicted,
various interface elements can be arranged to improve and enable
functionality and engagement.
[0190] FIG. 32 is a schematic diagram of an example UI mockup
(alert subscription) for an Alert Delivery Service. As depicted,
various interface elements can be arranged to improve and enable
functionality and engagement.
[0191] The following describes various components of an example
process for creating a new alert in an Alert Delivery Service:
Alert software development life cycle.
[0192] Business users use an Alert Admin UI (A) to edit/add new
alerts to the catalog of alerts "known by" the Alert Delivery
Service. For each alert, users define: [0193] Alert ID (e.g.
SignficantDepositAlert, PasswordChangeAlert, FailedLoginAlert,
etc.) [0194] Alert-data keys and associated types (e.g. [AccountID,
integer], [Balance, float], [TxnDate, date], etc. [0195]
Template-data keys and associated types (e.g. [FirstName, string],
[LastName, string], [AccountName, string], etc. [0196] Alert
template/s [0197] Name of the template (typically the same as the
Alert ID) [0198] Supported target types (e.g. SMS, Email, etc.) for
this particular alert [0199] Alert Trigger/s [0200] Value-based
triggers (e.g. Account Balance<threshold, AccountID, etc.)
[0201] Time-based triggers (e.g. date-time)
[0202] The Alert Admin UI uses the Alert Maintenance Service to
store data in an Alert Definitions DB. A new workflow is started in
BPM to track the enablement of the new alert (e.g. creation of
suitable templates, development of alert-detection rule/s in
BE--assuming Hub-based detection, etc.)
[0203] The BPM workflow is used to drive (and track) the end-to-end
rollout of the new alert.
[0204] Status of new and in-development alerts can be tracked.
[0205] The following describes various components of an example
Alert Subscription process of an Alert Delivery Service according
to some embodiments.
[0206] A customer subscribes to alerts by using a channel-provided
Alerts Preferences & Subscriptions UI. The UI queries an Alert
Descriptor Service which reads from the Alert Definitions DB to
obtain metadata about available alerts (e.g. alert ID,
English/French label, alert type, associated trigger/s, supported
target type/s, etc.) and renders an appropriate form (based on the
alert metadata). The user provides values for alert triggers (such
as Account ID, Balance Threshold) and target/s (e.g. Email, SMS)
creating an "alert subscription". The Alert Prefs and Subscriptions
UI (E) uses the Alert Subscription Service to write the customer's
"alert subscription" into AE data store.
[0207] The following describes various components of an example
Alert Generation process of an Alert Delivery Service according to
some embodiments.
[0208] In some embodiments, at runtime, alerts are generated in one
of two ways, Hub-Based Alert Detection and Non-Hub-Based Alert
Detection.
[0209] In Hub-based Alert Detection, each customer's alert
subscriptions and preferences, stored in AE data store (G), are
made available to Alert Detection in the base of Hub-based
alert-detection--likely via ActiveSpaces or VCI. Business events
from various product systems are intercepted by the Hub's Sense and
Respond capability and are passed to "alert detection rule-set/s"
(I) within the Hub (likely based on Business Events). "Alert
detection rule-set/s" detect when the conditions ("triggers")
specified in a given alert subscription are met and generate
appropriate alerts, which are sent to the Alert Delivery Service
for delivery.
[0210] In Non-Hub-based Alert Detection, Alert Sources which might
be channels, product systems, etc.--need knowledge of a customer's
alert subscriptions. They can obtain this information either by
replicating customer alert subscriptions and preferences from AE
data store or by using the Alert Subscription Service. Alert
Sources then use logic to "detect" conditions warranting alerts and
generate the appropriate alert XML messages, which are sent to the
Alert Delivery Service for delivery.
[0211] The following describes various components of an example
Alert History & Analytics feature of an alert delivery service,
according to some embodiments. Each alert that is processed by the
Alert Delivery Service is recorded in an Alerts History datastore,
allowing alert usage, trends, etc. to be analyzed. Analytics
applications can either directly access the Alerts History
datastore, or can access data about a given customer's alert
history via the Alert History Service.
[0212] In some embodiments, an alert delivery service can be
implemented according to an Incremental Build process, an example
being depicted in FIG. 33. In some embodiments, the Alert Delivery
Service can be implemented using an incremental approach which can
try to eliminate and encapsulate dependencies on components (such
as ECIF, template repository/ies, etc.) and enable iterative
delivery of the Alert Delivery Service components. As such, the
components and capabilities represented by example architectures
described herein can be developed over multiple releases, with
subsequent releases incrementally adding integration with ECIF (for
linkage with customer profile).
[0213] FIG. 34 depicts an example architecture of an example Phase
1 of an Alert Delivery Service build, according to some
embodiments. As depicted, there can be provided a single concrete
entry in the alerts taxonomy (1) (e.g. eStatementNotification),
simple "mechanical" service (A) that exercises end-to-end flow,
single target-type (email) (B), and no dependencies on ECIF or
template repository.
[0214] FIG. 35 depicts an example architecture of an example Phase
2 of an Alert Delivery Service build, according to some
embodiments. As depicted, during Phase 2, the architecture can
additionally include an added interface to AE data store (C) to
retrieve customer preferences, added interface to runtime template
repository (D), and additional target-type (SMS) (E).
[0215] In some embodiments, an Alert Delivery Service provides the
ability to send outbound (customer) alerts to customers in the form
of emails, SMS messages, etc. taking into account customer
communication and other preferences. The Alert Delivery Service's
scope includes sending customer alerts (e.g. send an
"alert"--offer, notification or alert--to a customer).
[0216] FIG. 36 is a schematic diagram showing example Component
Interaction in relation to an Alert Delivery Service, according to
some embodiments. As depicted, Hub CG&SR includes an Alert
Delivery Service as well as a DTS DB Access component, which can
transmit data to a database unit. The Alert Delivery Service can
receive data from business process management, customer connect,
and System units, through a SOA Gateway component.
[0217] The following table describes significant architectural
design decisions that may be reflected in some embodiments of an
Alert Delivery Service architecture and how these decisions bring a
bank (or other organization) to a desired target state.
TABLE-US-00006 Architecture Rationale for the Decision Type Topics
Decision Summary Decision Architectural Preference Use AE data
store to store Contain Alert Engine Placement customer
communication specific artefacts preferences, linked to the within
solution ECIF at the profile level. package Architectural
Notification to The ADS will use a fire-and- Maximize throughput
Alert Sources forget approach and will not and scalability by
notify alert sources when implementing an alerts are sent and/or
asynchronous delivered. Only failures will be interface. reported
(via an error queue). Management Implementation The ADS will be
implemented Complexity, risk Strategy using a phased approach, with
mitigation. initial release(s) building a simple delivery
"pipeline" with no dependencies on MDM. As additional aspects (e.g.
Gear2) become known subsequent phases will implement additional
capabilities.
[0218] In some embodiments, the system can provide for monitoring
adds, changes and deletes to a portfolio as follows.
TABLE-US-00007 Portfolio Monitoring Application View Number of new
applications added 0 Number of applications retired 0 HUB VIEW
Number of applications changed Adaptor to HUB 0 Migrated to HUB 0
Leverage existing service in HUB 0
[0219] The "number of apps changed" can be tabulated to include key
functions and apps that have been changed in the following ways:
[0220] Connected to the HUB via an adaptor [0221] Consumption of
CIF information from MDM/HUB [0222] Consumption Analytic
information from HUB and/or Virtual EDW [0223] Migration of
orchestration to the HUB [0224] Migration of business logic to the
HUB [0225] Migration of presentation logic to the HUB [0226] Moved
to strategic standards from non-strategic standards (includes
platforms)
[0227] Some use cases of some embodiments of an alert delivery
service system follow.
[0228] In order to demonstrate collaboration between key
components, the following use cases can be considered
architecturally-significant: e-Statement Notification, Fraud Alert,
and Credit Card Offers.
[0229] In an example process for e-Statement Notifications, an
e-Statement notification ("alert message") is received by the Alert
Delivery Service (ADS). Customer preferences indicate that "low
priority" notifications (like e-statement notifications) should be
sent via email and may not be sent between 8 am and 5 pm. The
"alert" is received by ADS at 10 am in the morning and is held
until 5 pm, at which time it is scheduled to be sent to the
customer as an email.
[0230] In an example process for Fraud Alerts, data indication that
a customer's Master Card has been frozen due to possible fraud, is
received by the ADS. Customer preferences indicate that "high
priority" notifications (like fraud notifications) should be sent
via SMS and be sent immediately. Even though there are thousands of
e-statement notifications being processed, the ADS schedules the
fraud alert for immediate delivery, giving it priority over other,
"lower priority" alerts.
[0231] In an example process for Credit-card Offers, an offer for a
new credit-card is sent to the ADS to be delivered to a customer.
The customer has previously opted out from CEM (commercial
electronic messages) and this decision is reflected in the
customer's anti-spam preferences stored in MDM. The ADS suppresses
the offer message and a notification is posted (via an error
queue). In some embodiments, the alert source would have been aware
of the customer preferences up front and would not have sent an
offer.
[0232] FIG. 37 is a schematic diagram of an example process for
UC1: sending e-Statement Notifications, according to some
embodiments. As depicted, at 1, product systems unit sends batch
data to an item processor. At 2, the item processor sends data to
generate paper statements. At 3, the item processor sends data to
generate eStatements. At 4, the item processor sends batch results
to real-time processing unit. At 5, an alert is sent from an Alert
Delivery Service included in a Hub to a formatting and delivery
unit. At 6, the formatting and delivery unit sends a formatted
alert via SMS to a target, for example, a mobile device. At 7, a
customer unit sends data to a browser, which can interconnect with
an online banking system unit, which can interconnect with other
components to generate eStatements.
[0233] In some embodiments, various infrastructures and network
topologies can be used to implement various embodiments of an Alert
Delivery Service.
[0234] An Alert Delivery Service in various embodiments can have
the following performance metrics.
TABLE-US-00008 Non-functional requirement Embodiment A Embodiment B
Embodiment C Availability 99.9% 99.9% 99.9% Disaster Recovery
"Response Time" <10 sec <10 sec ,10 sec (that is, time taken
to deliver alert once it is received by ADS) Transactional volume
~10 alerts/sec ~50 alerts/sec ~200 alerts/sec Maximum spike volume:
~300 alerts/sec Capacity ~10% growth/year
[0235] Various data models can be used by an Alert Delivery Service
in various embodiments and implementations.
[0236] The embodiments of the devices, systems and methods
described herein may be implemented in a combination of both
hardware and software. These embodiments may be implemented on
programmable computers, each computer including at least one
processor, a data storage system (including volatile memory or
non-volatile memory or other data storage elements or a combination
thereof), and at least one communication interface.
[0237] Program code is applied to input data to perform the
functions described herein and to generate output information. The
output information is applied to one or more output devices. In
some embodiments, the communication interface may be a network
communication interface. In embodiments in which elements may be
combined, the communication interface may be a software
communication interface, such as those for inter-process
communication. In still other embodiments, there may be a
combination of communication interfaces implemented as hardware,
software, and combination thereof.
[0238] Throughout the foregoing discussion, numerous references
will be made regarding servers, services, interfaces, portals,
platforms, or other systems formed from computing devices. It
should be appreciated that the use of such terms is deemed to
represent one or more computing devices having at least one
processor configured to execute software instructions stored on a
computer readable tangible, non-transitory medium. For example, a
server can include one or more computers operating as a web server,
database server, or other type of computer server in a manner to
fulfill described roles, responsibilities, or functions.
[0239] The foregoing discussion provides many example embodiments.
Although each embodiment represents a single combination of
inventive elements, other examples may include all possible
combinations of the disclosed elements. Thus if one embodiment
comprises elements A, B, and C, and a second embodiment comprises
elements B and D, other remaining combinations of A, B, C, or D,
may also be used.
[0240] The term "connected" or "coupled to" may include both direct
coupling (in which two elements that are coupled to each other
contact each other) and indirect coupling (in which at least one
additional element is located between the two elements).
[0241] The technical solution of embodiments may be in the form of
a software product. The software product may be stored in a
non-volatile or non-transitory storage medium, which can be a
compact disk read-only memory (CD-ROM), a USB flash disk, or a
removable hard disk. The software product includes a number of
instructions that enable a computer device (personal computer,
server, or network device) to execute the methods provided by the
embodiments.
[0242] The embodiments described herein are implemented by physical
computer hardware, including computing devices, servers, receivers,
transmitters, processors, memory, displays, and networks. The
embodiments described herein provide useful physical machines and
particularly configured computer hardware arrangements. The
embodiments described herein are directed to electronic machines
and methods implemented by electronic machines adapted for
processing and transforming electromagnetic signals which represent
various types of information. The embodiments described herein
pervasively and integrally relate to machines, and their uses; and
the embodiments described herein have no meaning or practical
applicability outside their use with computer hardware, machines,
and various hardware components. Substituting the physical hardware
particularly configured to implement various acts for non-physical
hardware, using mental steps for example, may substantially affect
the way the embodiments work. Such computer hardware limitations
are clearly essential elements of the embodiments described herein,
and they cannot be omitted or substituted for mental means without
having a material effect on the operation and structure of the
embodiments described herein. The computer hardware is essential to
implement the various embodiments described herein and is not
merely used to perform steps expeditiously and in an efficient
manner.
[0243] For simplicity only one computing device 2100 is shown in
FIG. 2, but the respective systems may include more computing
devices operable by users to access remote network resources and
exchange data. The computing devices 2100 may be the same or
different types of devices. The computing device 2100 includes at
least one processor, a data storage device (including volatile
memory or non-volatile memory or other data storage elements or a
combination thereof), and at least one communication interface. The
computing device components may be connected in various ways
including directly coupled, indirectly coupled via a network, and
distributed over a wide geographic area and connected via a network
(which may be referred to as "cloud computing").
[0244] Although the embodiments have been described in detail, it
should be understood that various changes, substitutions and
alterations can be made herein.
[0245] Moreover, the scope of the present application is not
intended to be limited to the particular embodiments of the
process, machine, manufacture, composition of matter, means,
methods and steps described in the specification. As one of
ordinary skill in the art will readily appreciate from the
disclosure of the present invention, processes, machines,
manufacture, compositions of matter, means, methods, or steps,
presently existing or later to be developed, that perform
substantially the same function or achieve substantially the same
result as the corresponding embodiments described herein may be
utilized. Accordingly, the appended claims are intended to include
within their scope such processes, machines, manufacture,
compositions of matter, means, methods, or steps.
[0246] As can be understood, the examples described above and
illustrated are intended to be exemplary only.
* * * * *
References