Note: Descriptions are shown in the official language in which they were submitted.
CA 02677147 2009-07-31
WO 2008/111965
PCT/US2007/061694
1
Cross ¨ Platform Data Processing
FIELD OF THE INVENTION
This invention relates to the common processing of data held of disparate data
processing systems, and in particular to the extraction of data for a common
purpose
from disparate systems running on different platforms.
BACKGROUND TO THE INVENTION
Many commercial organisations have grown large by acquisition of companies.
Acquired companies have their own computer systems, databases, customer
records
and processes which run off platforms which may be proprietary and which were
not
designed nor intended to interface with any other system. While this problem
is
prevalent in many industries, it is particularly acute in the financial
industry where
larger banks have acquired many smaller banks. In addition, banking systems
have
developed in an era when cross-border banking was limited. In the United
States,
until relatively recently, there were severe restrictions on the ability of
banks to
operate across state borders. In Europe, the development of the single
European
market within the European Union, together with a general trend to liberalise
the
financial markets has seen banks expand from operating in geographically
separate
-.regions to operating internationally across state or national borders. This
development has caused very substantial technical problems in integrating the
different non-standard computer systems operated by the various parts of an
organisation.
Thus, in the United States, banking core deposit systems have been limited to
specific geographical areas defined by the bank's own operations and by non-
integrated purchases. No cross-system processing would occur between core
banking systems until a conversion was performed to integrate the geographic
region
into the larger entity. Such a conversion is extremely expensive and time
consuming
. and may require a complete replacement of all software and hardware in
a particular
region and pose very complex data migration problems. In practice, this
integration
often does not take place.
As a result of this non-integration, in larger banking institutions,
development of a
common solution to new product development requires development across a
number of different platforms. Thus, for the institution to introduce a new
product or
CA 02677147 2014-08-05
-
2
service to customers, for example, concurrent development of the product would
be
required on each of the existing platforms. In terms of development time, cost
and
manpower resources, this is clearly a most unattractive approach. Moreover, it
makes it extremely difficult to deliver a common experience to all customers
regardless of the geographical location. Thus, it is desirable not only to
avoid the
creation of equivalent solutions across multiple platforms but also to avoid a
complete replacement of non-integrated platforms.
The problems are exacerbated where a particular product offering requires
access to
different platforms, as the product cannot simply be offered as, a number of
identical
products delivered by different platforms.
The problems described above have been known and well understood for many
years. However, they have not been solved. A conventionally accepted solution
would be extremely expensive and require a lot of additional hardware
resources
due to a lack of physical capacity within available hardware. The commonly
accepted solution requires large amounts of data to be extracted from the
various
platforms and to be moved around to various platforms and be consolidated into
a
usable form for a single system. This will usually include reformatting
extracted data
into a common format which, in some circumstances, is very difficult,
particularly
where fields in one file format do not exist in another format.
SUMMARY OF THE INVENTION
The present invention aims to address the problems discussed above and to
provide
for integration of non-common platforms to deliver a single solution across
multiple
platforms.
. CA 02677147 2016-09-14
. .
' Our Ref.: 87075-9
3a
The invention is defined by the independent claims to which reference should
be made.
According to one aspect of the invention, there is provided a financial
transactions system
for processing data from a plurality of different data processing platforms.
The financial
transactions system comprises: a plurality of data processing platforms, each
of which
has a database; each of the plurality of data processing platforms being
configured for
extracting data from records stored at the data processing platform to form a
first data
extract file and a second file. The second file has data relating to at least
some of the
records stored at each of the plurality of databases. The financial
transactions system
further comprises a common data processing platform for processing the first
extract file
113 and the second file received from the plurality of different data
processing platforms. The
common data processing platform comprises: computer readable medium storing
instructions which, when executed by the common data processing platform,
cause the
common data processing platform to perform steps comprising: combining the
first data
extract files received from each of the plurality of plafforms into a combined
data extract
file; processing the second files for each platform against the combined data
extract file,
thereby to identify records from which data in the first data extract files
was extracted that
have a predetermined property; and processing the second files relating to
identified
records including formatting the second files for common data processing
platform and
parsing and reformatting the second files for the data processing platform on
which their
respective records reside.
According to another aspect of the invention, there is provided a method of
processing
financial transactions data from a plurality of different data processing
platforms. The
method comprises: extracting data from records stored in databases at each of
the
plurality of data processing platforms to form a first data extract file
and a second file having data relating to at least some of the records stored
at each data
processing platform. The first extract file and the second file have at least
one type of
information in common. The method further comprises: processing the first data
extract
files at a common data processing platform to combine the first data
CA 02677147 2015-08-26
Our Ref.: 87075-9
3b
extract files received from the plurality of data processing platforms for a
given record
to form a combined data extract file; processing the second files against the
combined data extract file to identify records having a predetermined
property; and
processing the second files relating to records identified as having the
predetermined
property including formatting each of the second files for the common data
processing platform and parsing and reformatting the second files for the data
processing platform on which the identified records reside.
In an embodiment of the invention, which processes data from a plurality of
different
data processing platforms, a plurality of data processing platforms each have
a
records database. Software at each of the plurality of data processing
platforms
extracts data from records stored at the data processing system to form a
first data
extract file and forms a second file having data relating to at least some of
the
records stored at each of the plurality of databases. A common data processing
platform processes the first extract file and the second file received from
the plurality
of different data processing platforms and comprises software for combining
the first
data extract files received from each of the plurality of platforms into a
combined data
extract file, and software for processing the second files for each platform
against the
combined data extract file, thereby to identify records from which data in the
first data
extract files was extracted that have a predetermined property Software is
also
provided for processing the second data files relating to identified records
including formatting the second data files for the data processing system on
which
their respective records reside.
Preferably the software at each of the data processing platforms formats the
second
data files from each of the plurality of data processing platforms to a common
format.
It is preferred that the software for processing the second data fifes
relating to
identified records comprises software for combining the identified second data
files
into a single file, the reformatting being performed on the single file.
CA 02677147 2014-08-05
3c
The first data extract files may include an indication of whether the data
record from
which the data in the file is extracted is eligible for a predetermined
operation. In one
embodiment the data in the first data extract files is extracted from account
records
and the eligibility is an indication of whether the account can receive
transactions.
Preferably, the first data extract files include data extracted from each
record held on
the data processing platform at which they are created. The second data files
may
comprise monetary transfer transaction data which may include source account
data
and destination account data.
The software running at the common data processing plafform may process the
monetary transfer transaction data of the second data files against the
combined
data extract file to identify transactions with ineligible destination account
data.
Embodiments of the invention are advantageous in any environment in which data
is
held on a number of different data processing platforms and needs to be
processed
in the same manner. The creation of extract files from the various platforms
avoids
the need to send the complete master records to the common platform. In an
environment such as a bank, the master records may be bank account records
each
of which may be a large as 10000 bytes per record. Embodiments of the
invention
avoid the need to transfer large files with large record sizes which otherwise
may be
prevented by data transfer rates and available storage units attached to any
single
platform. Moreover, embodiments of the invention avoid the problems associated
CA 02677147 2009-07-31
WO 2008/111965
PCT/US2007/061694
4
with handling incompatible file formats used for records on different
platforms that
arise if complete records are transferred. Handling of these different records
would
require multiple processing paths within the decision engine at the common
platform
based on the source platform which is highly undesirable. The use of a data
extract
file at each platform to create a small record with only the necessary data
elements,
resolves the data transfer/storage issues and eliminates the need to have
multiple
processing paths within the decision engine at the common platform.
Embodiments of the invention will now be described, by way of example only,
and
with reference to the accompanying drawings, in which:
Figure 1 is a schematic overview of a system embodying the invention; and
Figure 2 is a flow chart illustrating the steps performed in an embodiment of
the
invention.
Description of Preferred Embodiment
The principles underlying the invention are applicable to any .environment in
which it
is desirable to provide a common solution across a plurality of non-common
platforms. The specific example to be described is given in relation to the
banking
industry and relates to a scheme by which customers using a debit card for
purchase
have amounts spent on the card rounded up to the nearest whole amount. That
round up amount is then credited to a savings account with the same bank. The
savings account may be held by a different party. The bank may offer
incentives to
encourage customers to participate, such as matching the amount transferred to
the
savings account up to a certain predetermined amount over a period of time.
The
method is described in detail in PCT/US2006/030362 the contents of which are
incorporated by reference. This example is illustrative only and the general
principles
underlying the invention are more broadly applicable. However, it will be
appreciated
from the earlier discussion of non-integrated platforms that the process
requires a
number of operations to be performed across the bank's various deposit
platforms.
Moreover, as the savings account to which round-up amounts are credited is not
necessarily in the same name as the current or checking account, there is no
certainty that the two accounts will be held on the same platform. Indeed,
they may
be held on entirely different platforms which may operate in different
countries or
states and which may use incompatible data formats and structures. The
specific
technical problems that implementation of such a product raises include: how
to deal
CA 02677147 2009-07-31
WO 2008/111965
PCT/US2007/061694
with overdraft situations; how to identify and deal with closed recipient
accounts. how
to support incentives across multiple platforms without building multiple
systems; and
how to view data relating to which transactions were rounded, and by how much.
Each of these problems will be discussed in more detail.
=
5 In the delivery of this method, it is important that transfers of round-
up amounts to a
deposit account do not cause the current account to go into overdraft. If each
transaction is rounded up as it is transacted, there would be no way of
telling what is
. the state of the account. Clearly, this is undesirable for the customer and
would be a
serious disincentive to use of the system by customers. The business process
applied requires that all transactions that qualify for rounding are totalled
at the end of
a business day and a transaction summary is created to be the last posting of
the
day. If this posting shows the account to be in overdraft, then the
transaction is
modified to show a zero amount to indicate to the customer that rounding for
the
day's transactions did not take place. In order to implement this business
process,
each of the separate platforms used by the bank requires modification.
The requirement to identify closed recipient accounts poses a considerable
technical
problem. This requirement arises from the possibility that a customer may
specify a
closed account for receipt of round-up amounts or that a specified account may
have
become closed making it no longer possible to transfer round-up amounts to the
specified account. As the receiving account may not be held by the current
account =
holder, the current account holder may not be aware that the receiving account
has
been closed. In the past, this type of problem has been dealt with by
producing a
report of non-posted transactions, where the receiving account is closed and
then
manually processing the transactions on the list. The present invention
automates
this process and provides a technical solUtion which checks account status
across
different platforms for the.ability to accept posted round-up transactions.
The manner
in which this is achieved is described in more detail below.
The problem of supporting incentives, such as the offer by a bank to match
round-up
amounts transferred to a savings account up to a certain value and/or for a
limited
period of time may be solved by providing a database having central
functionality with
access point for each of the platforms which require access to the database.
The problems of viewing transactions data to show which transactions were
rounded
up and by how much across the multiple platforms may also be solved by the
central
CA 02677147 2009-07-31
WO 2008/111965
PCT/US2007/061694
6
functionality database. The database interfaces with each of the platforms and
takes
data from existing data warehouses and accounting systems to determine which
transactions are eligible for rounding up. The database then manipulates the
data
and flags which transactions were used. This information is sent to a
repository
where it is matched with the day's transactions in the repository database for
online
viewing.
It will be appreciated that the approach of using a central database enables
the
determination of which transactions are eligible for round-up to take place in
a
platform neutral environment which is greatly preferable to running parallel
processes
on each of the platforms that make the same determination.
Figure 1 shows a simplified diagram of a cross-platform data extraction system
embodying the invention. The system comprises a plurality of platforms 10(i)
to 10(n)
which contain data required to implement the round-up process described in
PCT/US2006/030362. Each of these platforms comprises a deposit system and in
the case of a nationwide or EU wide system, these may each be regional or
national
deposit systems. Within each of the platforms, a data extract is formed file
from the
account records which contains the following information:
(I) state entity
(ii) account number
(iii) account status
The latter status is an indication of whether the account is eligible to
receive
monetary transactions and is therefore essential information in the round-up
transfer
process. The extract files are both created and stored at the regional
platforms 10(i)
to 10(n) and are shown at 12(i) to 12(n) in Figure 1. Thus, each platform
forms an
extract file which has the minimal data described above for each account held
on the
platform. N extract files will be prepared, one for each of the platforms. It
will be
appreciated that it would be possible to split any of these filed into a
number of
separate files but a single file is easier to process. Only a small amount of
the data
stored in eachof the account records is extracted. Thus, the data extract file
is small
compared to the total dataheld in the account records
In addition to the file indicating account status, a file is also created by
each platform
which contains information needed to create monetary transfer transactions.
This file
CA 02677147 2009-07-31
WO 2008/111965
PCT/US2007/061694
7
contains transaction information for those checking accounts which have a
roundup
transaction for that processing day.
This file is formatted to the specification of a common input file which may
be used
for cross platform transfers. Such file formats are well known as the industry
has, for
many years. been able to transfer monetary amounts from one platform to
another
and from bank to bank. One example of a suitable file format is the Fidelity
Financial
Systems intersystem transfer monetary input file. This file includes the
following
information for account on which there is a transaction:
sending account entity
(ii) sending account number
(iii) transaction date
(iv) sending application debit transaction code =
(v) receiving account entity
(vi) receiving account number
(vii) receiving application credit transaction code.
In Figure 1, these files are shown as 14(i) to 14(n). Thus, the first files of
the first set
12(i) to 12(n) are data extract files which may be viewed as account status
files and
the files of the second set 140) to 14(n) are monetary transfer information
files. A
given account may or may not contribute to the monetary transfer information
file on
a given day, depending on whether there is any activity on the file. In one
embodiment, a given account only has a single monetary transfer on a given
day,
that transfer being the sum of all round-ups created. In contrast, there will
always be
account status data for each account in the account status extract file
provided from
each platform.
Figure 1 shows a common platform 16 which includes a decision engine and
receives
the two files for each processing entity. The suitable platform is a single
mainframe
LPAR cluster maintained at a single processing site. File transfer may be
performed
using the NDM process. NDM (Network Data Mover) is a well known process for
transfer of files between large computer platforms and is widely used in the
financial
services industry. Thus, the common platform 16 receives via NDM, two files
from
each of the entities on each platform 10(i) to 10(n).
At the common platform 16, the account extract files from each processing
entity or
platform are combined into a single VSAM file which is used to determine
whether
CA 02677147 2009-07-31
WO 2008/111965 PCT/US2007/061694
8
the receiving accounts are eligible to receive the monetary transaction. VSAM
(Virtual Storage Access Method) is a well-known IBM file management system.
Thus, a single file is created which contains the account eligibility files
from all of the
platforms 10(i) to 10(n). The VSAM file is also, therefore, an account extract
file. In
Figure 1. this combined account extract file is shown at 18.
The common platform now has a combined account extract file and separate
monetary input transaction files for each of the platforms 10(i) to 10(n).
This enables
transactions where the receiving account is not eligible to be identified and
the
transfer not made. The receiving account may not be eligible because it does
not
exist or because its account status in the account extract file indicates that
it is not
eligible to receive-monetary transactions. This function is achieved by
processing the
monetary input transaction file for each platform or entity separately against
the
combined account extract file. Where the account status in the combined
extract file
shows ineligibility, the receiving account details in the combined extract
file are
changed to the sending. account. This means that the monetary amount to be
transacted is effectively returned to the sending account. Thus, the debit
previously
posted to this sending account is reversed as the amounts will not be posted
to the
recipient account. This process also alters the transaction description and
the
posting transaction code. These transaction descriptions reflect the various
dispositions of the transaction. Transactions that post the roundup amount to
the
savings account will have different descriptions from transactions that are
returned to
the checking account due to the savings account being in an ineligible status.
=
Posting transaction codes are defined within the specific deposit systems.
These
codes tell the deposit system which options to use in posting the transaction.
Once it has been determined which account should receive the monetary
transaction,
all the transactions are combined into a single input file. This process
occurs once a
day, after all the various deposit systems have completed the daily
processing. This
input file is formed at the common platform and is shown as 20 in Figure 1.
The file
contains transaction details for accounts which could be held on any of the
platforms
10(i) to 10(n). The file then needs to be processed to create reformatted
monetary
transactions and general ledger transactions. This process may be performed by
the
Fidelity intersystem transfer application referred to above.
This process is illustrated in Figure 1 at 22 with the transfer application
producing a
plurality of monetary and ledger transactions 22(i) to 22(m). At this stage;
the
CA 02677147 2015-08-26
Our Ref.: 87075-9
9
transactions are all in the same intersystem format and cannot be processed by
the
individual platforms. The common platform sends the transactions 22(i) to
22(m) to
a system exchange application 24, which reformats each transaction according
to
the platform on which the account to which the transaction relates, is held.
Thus,
each transaction is formatted correctly for each specific deposit application.
The
transactions can then be sent to the individual deposit systems for
processing.
Figure 2 shows a flow chart of the steps in the file processing operation
described
above. At step 100, each of the platforms creates the transaction eligibility
extract file
and at step 102 each of the platforms creates the monetary transaction file.
These are
received by the common platform at step 104 and the combined account extract
file is
created at step 106. At step 108, the transaction files are received and at
step 110
these files are processed against the account extract file. At step 112, the
common
platform determines, for each transaction, whether the receiving account is
eligible
and if not, at step 114 performs the account destination switch described
above. If the
receiving account is eligible, processing is continued and all the eligible
transactions
are combined into a single file at step 116. These files are reformatted at
step 118 to
create the correct file format for each destination deposit application. At
step 122,
each of the platforms receives transaction data relating to accounts held on
its
platform and in a format that is compatible with the platform.
The embodiment described enables cross-platform processing by creating extract
files
that only contain a small portion of the large amounts of non-common data held
in the
account files on each of the platforms. These extract files are transferred to
a common
platform where two separate extract files are combined to form a single
extract file for
each account. Common tasks are performed against the data received from all
the
deposit platforms at the common platform.
CA 02677147 2015-08-26
Our Ref.: 87075-9
9a
This approach enables genuine cross platform data processing to be performed,
with
the same processing being applied to selected date from each deposit platform.
Thus, a single processing operation is required for data from all the
platforms in
contrast to the prior art approach where separate, but similar, processing is
performed at each of the platforms. The embodiment described has the advantage
that all customers may receive the same customer experience regardless of the
geographic region in which they are located. In the case of a banking system,
it
enables customers who have accounts in several different regions to transfer
funds
easily between the accounts. In the case of the round-up method described
above
CA 02677147 2009-07-31
WO 2008/111965
PCT/US2007/061694
and in PCT/US2006/030362, it enables funds to be transferred in response to a
round-up performed on a customer's current account. to a savings account that
is
held by any party and which resides on any platform operated by the bank.
Moreover, it enables the bank to operate incentive schemes which provide the
same
5 incentives for all customers irrespective of geographical location or
account type. For
example. in the round-up system described, it enables the bank to credit the
savings
account selected by the customer with an amount equal to that transferred by
the
round-up operation, or any other amount as desired, subject to a limit in the
amount
credited over a given period of time and/or the period.of time for which the
incentive
10 is available.
The creation of extract files from the various deposit platforms avoids the
need to
send the complete account master records to the common platform. The account
master records can be a large as 10000 bytes per record. Transferring large
files
with large record sizes is inhibited by data transfer rates and available
storage units
attached to any single platform. Account master records from different deposit
platforms have incompatible file layouts. Handling of these different records
would
require multiple processing paths within the decision engine at the common
platform
based on the source deposit system which is highly undesirable. Allowing each
deposit system to create a small record with only the necessary data elements,
resolves both the data transfer/storage issues and the need to have multiple
processing paths within the decision engine at the common platform.
Although the system and method embodying the invention have been described in
the context of a financial system, it will be appreciated that the invention
may be
applied to any system which requires a common processing to be applied to data
which is resident on, and processed by, separate and non-compatible computer
systems.
Many modifications to the embodiments described are possible within the scope
of
the inVention and the invention is limited only by the scope of the following
claims.
