EP2126729A2

EP2126729A2 - Cross-platform data processing

Info

Publication number: EP2126729A2
Application number: EP07710465A
Authority: EP
Inventors: Steven M. Grill; Bobby Lee Britton; Jack Vardy; Gary Eugene Smiley
Original assignee: Bank of America Corp
Current assignee: Bank of America Corp
Priority date: 2007-02-06
Filing date: 2007-02-06
Publication date: 2009-12-02
Also published as: WO2008111965A3; EP2126729A4; CN101632077B; CN101632077A; CA2677147C; CA2677147A1; WO2008111965A2

Abstract

In a financial transaction system data records are held on a plurality of independent data processing platforms. At each platform, data extract files are formed which identify records that are eligible for a certain type of transaction and further data files are formed which comprise monetary transfer transaction data. Both types of file are passed to a common data processing platform from all the independent platforms and the extract files for each record are combined to form a single file containing information about each record held across the platforms. This single file is then processed against the monetary transaction transfer files. Ineligible transactions are identified and blocked by switching destination data to source data. The transactions are then combined into a single file which is passed to a transaction exchange application which reformats each transaction into the correct format for the platform on which the record to which it relates is stored.

Description

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 separateregions 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 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.

The invention is defined by the independent claims to which reference should be made.

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

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 platform 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 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 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.

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 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(π) 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 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 (n) sending account number

(in) transaction date

(ιv) 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(ι) to 14(n) Thus, the first files of the first set 12(ι) to 12(n) are data extract files which may be viewed as account status files and the files of the second set 14(ι) 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 piocess 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(ι) 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 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 transactions are all in the same intersystem format and cannot be processed by the individual platforms The common platform sends the transactions 22 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 1 14 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 1 18 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

This approach enables genuine cross platform data processing to be performed, with the same processing being applied to selected data 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 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 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 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.

Claims

1. A system for processing data from a plurality of different data processing platforms, comprising:

a plurality of data processing platforms, each data processing platform having a database;

software at each of the plurality of data processing platforms for extracting data from records stored at the data processing system to form a first data extract file and a second file having data relating to at least some of the records stored at each of the plurality of databases; and

a common data processing platform for processing the first extract file and the second file received from the plurality of different data processing platforms, the common data processing platform comprising:

software for combining the first data extract files received from each of the plurality of platforms into a combined data extract file;

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; and

software 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.

2. A system according to claim 1. wherein 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.

3. A system according to claim 1 or 2, wherein the software for processing the second data files relating to identified records comprises software for combining the identified second data files into a single file, and wherein the reformatting is performed on the single file.

4. A system according to claim 1. 2 or 3, wherein the first data extract files includes an indication of whether the data record from which the data in the file is extracted is eligible for a predetermined operation.

5. A system according to claim 4. wherein 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.

6. A system according to any of claims 1 to 5. wherein the second data files comprise monetary transfer transaction data.

7. A system according to claim 6, wherein the monetary transfer transaction data includes source account data and destination account data.

8. A system according to claim 6 or 7, wherein the software running at the common data processing platform processes the monetary transfer transaction data of the second data files against the combined data extract file to identify transactions with ineligible destination account data.

9. A system according to any preceding claim, wherein the first data extract files include data extracted from each record held on the data processing platform to at which they are created.

10. A method of processing data from a plurality of different data processing platforms comprising:

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, wherein the first extract file and the second file have at least type of information in common;

processing the first data extract files at a common data processing platform to combine the first data extract files received from the plurality of data processing platforms for a given record to form a combined data extract file;

processing the second data files against the combined data extract file to identify records having a predetermined property; and processing the second data files relating to records identified as having the predetermined property including formatting each of the second data extract files for the data processing system on which the identified records reside

11 A method according to claim 10 wherein the step of forming the second data files comprises formatting the extracted data from records on each of the data processing platforms to a common format

12 A method according to claim 10 or 11 , wherein the processing of the second data files relating to identified records comprises combining the data relating to identified records into a single file and wherein the reformatting is performed on the single file

13 A method according to claim 10, 11 or 12, wherein the first data extract files includes an indication of whether the records from which the data in the file is extracted are eligible for a predetermined operation

14 A method according to claim 13, wherein the first data extract files are extracted from account records and the eligibility is an indication of whether the accounts can receive transactions

15 A method according to any of claims 10 to 14, wherein the second data files comprise monetary transfer transaction data

16 A method according to claim 15, wherein the monetary transfer transaction data includes source account data and destination account data

17 A method according to any one of claims 15 or 16, wherein the processing at the common data processing platform processes the monetary transfer transaction data of the second data t files against the combined data extract file to identify transactions with ineligible destination account data

18 A method according to claim 17, comprising altering the destination account data of transactions identified as ineligible to the source account data

19 A method according to any of claims 10 to 17, wherein the first data extract files include data extracted from each record held on the data processing platform to at which they are created 20 A method according to any of claims 10 to 19 wherein the data extract files framed at each of the platforms each contain the same data extract for each reocrd stored at the platorms

21 A method according to any of claims 10 to 20 wherein the information held in common by the first extract file and the second file is an account number

22 A computer program product which when run on a data processing system having a plurality of different data processing platforms and a common data processing platform, causes the system to perform the method of any of claims 10 to 21

23 Computer software which when run on a data processing system having a plurality of different data processing platforms and a common data processing platform, causes the system to perform the method of any of claims 10 to 21