CA2677147C - Cross-platform data processing - Google Patents
Cross-platform data processing Download PDFInfo
- Publication number
- CA2677147C CA2677147C CA2677147A CA2677147A CA2677147C CA 2677147 C CA2677147 C CA 2677147C CA 2677147 A CA2677147 A CA 2677147A CA 2677147 A CA2677147 A CA 2677147A CA 2677147 C CA2677147 C CA 2677147C
- Authority
- CA
- Canada
- Prior art keywords
- data
- files
- file
- data processing
- extract
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/02—Banking, e.g. interest calculation or account maintenance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/25—Integrating or interfacing systems involving database management systems
- G06F16/258—Data format conversion from or to a database
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
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 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 -
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 -
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 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.
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 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.
=
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 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 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 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 Our Ref.: 87075-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.
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 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.
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 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.
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 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.
=
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 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 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 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 Our Ref.: 87075-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.
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 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.
Claims (22)
1. A financial transactions 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;
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 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 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 platforms 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 the common data processing platform and parsing and reformatting the second files for the data processing platform on which their respective records reside.
a plurality of data processing platforms, each data processing platform having 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 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 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 platforms 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 the common data processing platform and parsing and reformatting the second files for the data processing platform on which their respective records reside.
2. A system according to claim 1, wherein the computer readable medium further stores instructions which, when executed by the common data processing platform, cause the common data processing platform to format the second 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 processing the second files relating to identified records comprises combining the identified second 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 financial transactions.
6. A system according to any of claims 1 to 5, wherein the second 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 computer readable medium further storing instructions which, when executed by the common data processing platform, cause the common data processing platform to process the monetary transfer transaction data of the second files against the combined data extract file to identify transactions with ineligible destination account data.
9. A system according to any of claims 1 to 8, wherein the first data extract files include data extracted from each record held on the data processing platform at which they are created.
10. A method of processing financial transactions 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 data extract file and the second file have at least one 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 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.
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 data extract file and the second file have at least one 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 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.
11. A method according to claim 10, wherein the step of forming the second 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 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 financial transactions.
15. A method according to any of claims 10 to 14, wherein the second 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 anyone of claims 15 or 16, wherein the processing at the common data processing platform processes the monetary transfer transaction data of the second 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 at which they are created.
20. A method according to any of claims 10 to 19, wherein the data extract files formed at each of the platforms each contain the same data extract for each record stored at the platforms.
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.
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.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/US2007/061694 WO2008111965A2 (en) | 2007-02-06 | 2007-02-06 | Cross-platform data processing |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2677147A1 CA2677147A1 (en) | 2008-09-18 |
| CA2677147C true CA2677147C (en) | 2017-08-01 |
Family
ID=39760248
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA2677147A Expired - Fee Related CA2677147C (en) | 2007-02-06 | 2007-02-06 | Cross-platform data processing |
Country Status (4)
| Country | Link |
|---|---|
| EP (1) | EP2126729A4 (en) |
| CN (1) | CN101632077B (en) |
| CA (1) | CA2677147C (en) |
| WO (1) | WO2008111965A2 (en) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070033134A1 (en) | 2005-08-02 | 2007-02-08 | Bank Of America Corporation | Automatic Savings Program |
| US20150081411A1 (en) | 2008-02-08 | 2015-03-19 | Bank Of America Corporation | Enhanced Automatic Savings Program |
| CN104778174A (en) * | 2014-01-10 | 2015-07-15 | 腾讯科技（深圳）有限公司 | Data output control method and equipment |
| US10817880B2 (en) | 2015-09-03 | 2020-10-27 | Bank Of America Corporation | In-it-together savings goal feature |
| US10817934B2 (en) | 2015-09-03 | 2020-10-27 | Bank Of America Corporation | Single enrollment process for all payment vehicles |
| US10817933B2 (en) | 2015-09-03 | 2020-10-27 | Bank Of America Corporation | Financial health smartwatch |
| US10157420B2 (en) | 2015-09-03 | 2018-12-18 | Bank Of America Corporation | Systems and methods for additional notification and inputs of electronic transaction processing results |
| US10169820B2 (en) | 2015-09-03 | 2019-01-01 | Bank Of America Corporation | Systems and methods for display notifications for routing of electronic transaction processing results |
| US10169749B2 (en) | 2015-09-03 | 2019-01-01 | Bank Of America Corporation | Systems and methods for tracking and adjustment of electronic transaction processing results |
| CN106845959A (en) * | 2017-01-20 | 2017-06-13 | 深圳前海微众银行股份有限公司 | Transfer account method and device |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6721713B1 (en) * | 1999-05-27 | 2004-04-13 | Andersen Consulting Llp | Business alliance identification in a web architecture framework |
| US20040006566A1 (en) * | 2000-11-07 | 2004-01-08 | Matt Taylor | System and method for augmenting knowledge commerce |
| WO2005006138A2 (en) * | 2003-06-30 | 2005-01-20 | Idocuments, Llc | Worker and document management system |
| CN1750033A (en) * | 2004-09-17 | 2006-03-22 | 王键 | Electronic bill transaction system based on cell phone and its mobile communication network |
-
2007
- 2007-02-06 CA CA2677147A patent/CA2677147C/en not_active Expired - Fee Related
- 2007-02-06 EP EP07710465A patent/EP2126729A4/en not_active Ceased
- 2007-02-06 CN CN2007800509965A patent/CN101632077B/en not_active Expired - Fee Related
- 2007-02-06 WO PCT/US2007/061694 patent/WO2008111965A2/en active Application Filing
Also Published As
| Publication number | Publication date |
|---|---|
| CA2677147A1 (en) | 2008-09-18 |
| EP2126729A2 (en) | 2009-12-02 |
| WO2008111965A2 (en) | 2008-09-18 |
| WO2008111965A3 (en) | 2008-11-06 |
| EP2126729A4 (en) | 2012-01-25 |
| CN101632077B (en) | 2012-07-18 |
| CN101632077A (en) | 2010-01-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2677147C (en) | Cross-platform data processing | |
| US7254554B2 (en) | Accounting system and method for processing transaction data | |
| US7912784B2 (en) | Methods and systems for processing, accounting, and administration of stored value cards | |
| US7490059B2 (en) | Methods and systems for consolidating financial reporting information | |
| US20010025262A1 (en) | Computer apparatus for monitoring and updating accountancy records | |
| US20030163398A1 (en) | Device for integrating transaction information on finantial transaction | |
| JP2004213124A (en) | Fund management method and system | |
| US7752097B2 (en) | Methods, systems and articles of manufacture for managing penalty fees for financial accounts | |
| US20130179443A1 (en) | Generating A Pivot Table From An Aggregated Data Set | |
| US20040111344A1 (en) | Financial data reporting system | |
| Keyes | Banking technology handbook | |
| EP1542147A2 (en) | Global balancing tool | |
| JP4282882B2 (en) | Spending management system, spending management method, and storage medium | |
| JP6183867B1 (en) | Notional pooling system and notional pooling method | |
| Mulligan | EDI in foreign trade: Case studies in utilisation | |
| US7725391B1 (en) | Savings system based on time of transaction | |
| CA2383126A1 (en) | Configurable anonymous trading system | |
| US7546304B1 (en) | Configuring keys for use in processing business data | |
| US20110060668A1 (en) | System and method for generating a combined statement | |
| US20220230153A1 (en) | Payment manager having data enrichment tool | |
| JP4313375B2 (en) | Claims liquidation management method, claims liquidation management system, and claims | |
| US20240070661A1 (en) | Transaction system transfer techniques | |
| CN113222568A (en) | Shipping service settlement method, platform, equipment, medium and product | |
| JP2001084304A (en) | Data preparation system for consolidated account settlement | |
| CN114298682A (en) | Draft information management control method and device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |
Effective date: 20220207 |