|
|
|
CubeIQ
Solutions and Systems |
|
 |
Welcome
to
CubeIQ products and
systems web
pages.
|
|
CubeIQ Products and Systems |
|
Group:
Enterprise Software Applications |
|
|
|
Risk and Compliance Solutions |
|
Anti
Money Laundry (AML) Software Applications |
|
Transaction Pattern Analysis
|
|
|
|
Transaction
Pattern Analysis in CaratAML™ |
|
There
are three major steps in the transaction pattern
analysis: |
|
 |
Data
gathering (ETL). |
|
 |
Implementation
of algorithms. |
|
 |
Results
Processing and Investigations. |
|
|
|
|
|
Data
gathering with ETL: Extraction, Transformation, Loading |
|
We
are supplying the necessary tools to load in a
transaction database all elements found in payment
transactions: |
|
 |
SWIFT
transfer messages. |
|
 |
SWIFT
transactions involving amounts although not
transferred. |
|
 |
Domestic
transfers. |
|
 |
Cards
Transactions from POSs, ATMs, Internet, other
alternative channels ... |
|
 |
Basic
transactions (deposits, withdrawals, ...). |
There
are facilities to select a subset of the data by using many
different keys, such as period, countries, individuals,
currencies, etc…
Data
selected are then entered regularly in datasets where
each is analyzed according to patterns.
The
same data may be entered in several datasets. Each data
keeps a link to the original data.
Every
individual encountered is created as an account; there
will be facilities to group accounts identifications as
synonyms, even in different currencies. Amounts are
loaded in their equivalent in the reporting currency.
The
main data database can also be loaded with ancient or
archived data: the datasets can be re-evaluated as and
when wished, for instance when an algorithm is modified
to reflect an additional element.
|
|
|
|
|
Algorithms |
|
We
are building terms of algorithms like a collection of
statistical or mathematical items: |
|
 |
Average
balance of transactions in a given period (day,
week, month, …). |
|
 |
Maximum
amount transferred. |
|
 |
Number
of transactions per period. |
|
 |
Absolute
value of transactions per period. |
Then
you can name complex algorithms to be applied to
particular sets of data.
The
system is supplied with few algorithms in order the user to understand
their building. Also a number of samples are provided
such as :
|
|
 |
Account
that receives and pay above X per day. |
|
 |
Account
that enters and exists very quickly everyday,
and has a very big volume in the same day, but a
small End - Of - Day (EOD) balance. |
|
 |
One
account receiving most of amounts from another
account. |
|
 |
One
account receives foreign funds and disperse to
same list most of the time. |
|
 |
Dormant
account becomes active with big amounts. |
|
 |
Account
becomes dormant after massive funds dispersion. |
|
|
|
|
Result
processing and investigations |
|
We are supplying the necessary tools to load in
a transaction database all elements found in
payment transactions.
Each
algorithm can have its alarm parameters, like which
report to produce and to whom it should be addressed.
Each
instance can have different parameter set.
As an instance
run the pattern analysis on a customer from a branch the
outcome could be returned to the
branch manager as well as the compliance manager.
When
a suspected pattern is detected, it becomes a case to be
further analyzed: it is then stored in a case database,
together with its details assembled in a delimited file
directly loadable in Excel ™ for detailed analysis and
decision making, including full details of originating
transaction.
From
there, the officers can analyze it, create follow-up
memos or messages, and assemble additional evidences to
the case constructed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|