CN114169887A - Reconciliation system based on distributed data nodes - Google Patents
Reconciliation system based on distributed data nodes Download PDFInfo
- Publication number
- CN114169887A CN114169887A CN202111477685.5A CN202111477685A CN114169887A CN 114169887 A CN114169887 A CN 114169887A CN 202111477685 A CN202111477685 A CN 202111477685A CN 114169887 A CN114169887 A CN 114169887A
- Authority
- CN
- China
- Prior art keywords
- data
- reconciliation
- error
- file
- bill
- 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.)
- Pending
Links
Images
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
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
-
- 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/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
Abstract
The invention provides a reconciliation system based on distributed data nodes, which comprises: the distributed node is used for butting payment systems of all transaction parties, and is provided with: the file acquisition module is used for downloading or reading the reconciliation files of all channels; the file analysis module is used for creating different analysis templates and acquiring the corresponding analysis template according to the channel and the file type for analysis; the account checking processing module is used for the business logic processing of account checking; and the error processing module is used for processing the orders in the error pool. The system can ensure real, transparent and traceable data, and improves timeliness and accuracy of account checking.
Description
Technical Field
The invention relates to the technical field of financial management systems, in particular to a reconciliation system based on distributed data nodes.
Background
The traditional account checking refers to account checking, and refers to checking and checking related data in an account book in order to ensure that the records of the account book are correct and reliable in accounting. In a bank or a third-party payment company, reconciliation is a process of confirming both parties of a transaction in a certain period, generally, the transaction in the previous day is cleared in the next day, a statement is generated for a platform merchant to download, and a settlement to be paid is settled to the platform merchant. And on the next layer, in the internet financial industry or the e-commerce industry, account checking is to confirm the correctness of the transaction and the fund with a payment provider (bank and third-party payment company) in a fixed period, so as to ensure that the transaction and the fund of both parties are consistent and correct.
Broadly speaking, all cross-application data interactions should theoretically be reconciled. So the reconciliation can also be divided into information flow reconciliation and fund flow reconciliation. The information flow reconciliation is generally used in the reconciliation of an internal system of the self, such as the payment data of a payment system and the business data of a business system, so as to ensure the consistency of fund transaction and business transaction. The fund flow reconciliation is the reconciliation of fund transactions between the payment system and the bank or the third party payment system.
The existing account checking technology mainly has the following defects:
1. the cooperative bank cannot know the loan repayment transaction detail information causing the change of the prepaid account in real time;
2. the cooperative business can not know whether the account is uneven or not in time;
3. the cooperative business needs to develop an account checking system by itself;
4. lack of a unified and comprehensive information view;
5. related data are inquired in the account checking process, if the data volume is large, the influence on the performance of the database is large, and account checking logic expansion is extremely troublesome;
6. the algorithm efficiency of the line-by-line comparison is low, but no good optimization room exists in the algorithm, and if the database INTERSECT, MINUS is adopted, the pressure on the database is high;
7. under the condition of large traffic, if hundreds of upstream channels need to be paired, each family has hundreds of thousands of transaction records, the load of an account checking server and a database server is high, even if reading and writing separation is adopted, a reading base is used during account checking, and the pressure is the same and very large;
8. the efficiency of importing batch files is low, and network connection and connection closing are needed each time.
In view of the above disadvantages, it is an object of the present invention to provide a reconciliation system capable of solving the above problems.
Disclosure of Invention
In order to overcome the defects of the prior art, the invention provides the account checking system based on the distributed data nodes, which can ensure the real and transparent traceability of data and improve the timeliness and accuracy of account checking.
In order to achieve the above object, the invention provides a reconciliation system based on distributed data nodes, which comprises: the distributed node is used for butting payment systems of all transaction parties, and is provided with:
the file acquisition module is used for downloading or reading the reconciliation files of all channels;
the file analysis module is used for creating different analysis templates and acquiring the corresponding analysis template according to the channel and the file type for analysis;
the account checking processing module is used for the business logic processing of account checking;
and the error processing module is used for processing the orders in the error pool.
Further, the file acquisition mode of the file acquisition module comprises active acquisition, opposite side pushing and manual uploading, the operation of downloading the file triggered at a fixed time point every day through a timing task is actively acquired, a retry mechanism is provided for the active acquisition, and the operation of re-downloading the file can be performed under the condition that the file downloading fails.
Furthermore, the file types analyzed by the file analysis module include, but are not limited to, EXCEL, TXT and CVC, the file analysis module analyzes the bill data and order data of different channels, then uniformly converts the bill data and order data and stores the bill data and order data into a general bill data table, the bill data table defines different data ends, assigns corresponding fields to the different data ends and fills the fields into the bill data table, the bill data table is stored by adopting a GlusterFS file, and the bill data table is stored on a Postgresql database.
Furthermore, the reconciliation processing module compares the reconciliation data with the payment order data after acquiring the bill data table, the reconciliation processing module respectively cleans the bill data and the payment order data into an intermediate table to be reconciled of the bill and an intermediate table to be reconciled of the order, then SQL full join operation is carried out on the two intermediate tables to obtain a total set, the set comprises an intersection and two complementary sets, the comparison of the order amount of the data set at the intersection part is consistent, so that no error exists, the bill data is taken from the flat data set according to the requirement of the settlement data, the total set of the platform order data service fields is combined, the reconciliation detail table is directly generated, and if the bill data and the payment order data are inconsistent, the error data are required to be generated and are recorded into the reconciliation error data table to be moved into the error pool.
Furthermore, the reconciliation data processed by the reconciliation processing module is stored by adopting a TIDB distributed relational database.
Further, the error information table records the detailed information of the error according to the error type, including but not limited to channel type, amount, transaction time, and classifies the error, defines a specific error type code, and classifies the error into: long, short, wrong.
Further, the handling of the long errors may include manual reconciliation, tie-out, or automatic handling.
Furthermore, the system for distributed node operation adopts an open source system, adopts GlusterFS as a storage system, and all transaction parties upload transaction flow and fund flow through HTTPS.
The reconciliation system based on the distributed data nodes utilizes the distributed multi-trust node technology to branch the reserve payment transaction information into nodes, ensures the reality and transparency of data to be traceable, solves the reconciliation problem of a payment system and a partner, reduces the labor and time cost of the partner, improves the timeliness and the accuracy of the reconciliation, is very suitable for the scenes of transaction data synchronization, reconciliation and the like in the financial industry, and solves the problem that the traditional batch file reconciliation mode cannot be solved for a long time.
Drawings
The present invention will be further described and illustrated with reference to the following drawings.
FIG. 1 is a system block diagram of a reconciliation system based on distributed data nodes according to a preferred embodiment of the present invention;
FIG. 2 is a flow diagram of a distributed data node based reconciliation system;
FIG. 3 is a flow chart of long error mitigation;
FIG. 4 is a flow chart of stub error cancellation.
Detailed Description
The technical solution of the present invention will be more clearly and completely explained by the description of the preferred embodiments of the present invention with reference to the accompanying drawings.
As shown in fig. 1, an account checking system based on distributed data nodes of the present invention includes: the distributed node is used for butting payment systems of all transaction parties, and is provided with:
the file acquisition module is used for downloading or reading the account checking files of each channel, the file acquisition mode of the file acquisition module comprises active acquisition, opposite side pushing and manual uploading, the operation of triggering the file downloading at a fixed time point every day through a timing task is actively acquired, a retry mechanism is actively acquired, and the file re-downloading operation can be carried out under the condition that the file downloading fails;
the file analysis module is used for creating different analysis templates, acquiring corresponding analysis templates according to channels and file types for analysis, wherein the file types analyzed by the file analysis module include but are not limited to EXCEL, TXT and CVC, the file analysis module analyzes the bill data and order data of different channels, then uniformly converts the bill data and order data and stores the bill data and the order data into a general bill data table, the bill data table defines different data ends, gives corresponding fields to the different data ends and fills the fields into the bill data table, the bill data table is stored by adopting a GlusterFS file, and the bill data table is stored in a Postgresql database;
the reconciliation processing module is used for performing business logic processing on the reconciliation, the reconciliation processing module compares the reconciliation data with the payment order data after acquiring the bill data table, the reconciliation processing module respectively cleans the bill data and the payment order data into a bill to be reconciled intermediate table and an order to be reconciled intermediate table, then carries out SQL full join operation on the two intermediate tables to obtain a set total, the set comprises an intersection and two complementary sets, if the data sets in the intersection part are consistent in order amount, the error-free condition is indicated, if the data sets in the flat data set are inconsistent, the bill data is taken according to the settlement data requirement, the platform order data business field total set is combined, the reconciliation detail table is directly generated, and if the data are inconsistent, the error data are required to be generated and are recorded into the reconciliation error data table and are moved into an error pool;
the error processing module processes orders in the error pool, the error information table records detailed information of the error according to the error type, including but not limited to channel type, money amount and transaction time, classifies the error, defines a specific error type code, and divides the error into: long, short, and monetary errors, and the handling of long errors may include manual reconciliation, tie-down, or automated handling.
The reconciliation system based on the distributed data nodes is based on a multi-trust node technology, the multi-trust node technology is a non-falsification distributed accounting book technology, and the multi-trust node technology is characterized in that a distributed accounting book is a biggest, namely, each participating mechanism on a chain has one accounting book together. All transaction information on the multi-trust node can be recorded and cannot be tampered, the reality and transparency of data can be guaranteed, and the method is very suitable for scenes such as transaction data synchronization and account checking in the financial industry.
The design principle is as follows:
the existing service is not influenced, and the service data is desensitized and then sent to the multi-trust node in a bypass uplink mode; a web system is developed, so that a cooperative bank can conveniently inquire account checking results on multiple trust nodes; the transmission and storage of the service data adopt an encryption mode, so that the data security is ensured; specifically, the reconciliation platform realized based on the multi-trust node technology has the following advantages: the method is simple to use, and the user can log in by accessing the web system through the intranet and inputting the account number and the password of the administrator; data real-time touch, real-time monitoring account balance of the prepared payment account on the same day, total sum of money put on the same day, total sum of money repayment on the same day, total sum of other money transferred on the same day and current data on the same day; the data security is high, and the communication and the storage of the data are encrypted; the data availability is high, data are mutually synchronized among multiple trust nodes, and the data availability is improved; the controllability of the cooperative rows is strong, the cooperative rows can freely select 1 to a plurality of nodes, the nodes can be selectively deployed in the cooperative rows or on a public cloud, and data between different cooperative rows are physically isolated, so that the privacy is protected.
Has the advantages that:
node intercommunication: according to the requirements of business functions, privacy protection, data isolation or performance capacity expansion, a plurality of independent chains are established to work in parallel, and the chains can interact with one another through cross-chain services, such as transaction sending, transaction result inquiring, configuration data reading and the like. Cross-chain interaction is currently the research focus in the field of multiple trust nodes, and deep exploration is needed in the aspects of safety, fraud prevention, data consistency, efficiency and the like. The method comprises the following steps: parallel and cross-chain consensus is realized, and the consensus efficiency is improved; the combined signature is used for replacing transaction execution to perform block verification, so that the transaction execution times are reduced; and performing cross-chain communication and data verification, realizing cross-chain safe transaction, and performing cross-chain reconciliation.
Distributed storage: in the existing multi-trust node implementation, each node stores the full amount of multi-trust node data, the data redundancy is high, the data capacity is influenced by single-machine storage hardware, and in mass service, if data in a longer time period needs to be stored, the data volume is not generally capable of being accommodated by a single server. The multi-trust node data is generally stored on a physical hard disk of the node based on a file system by adopting a file type local database, and a cross-network storage structure is not provided. In an organization with higher requirements on data security, data is generally stored in a security area isolated from an external network, so that the security of the data is guaranteed. Meanwhile, mature data storage and maintenance schemes are established by the mechanisms, high availability, capacity expansion, migration and maintenance of data storage services are guaranteed on the infrastructure level, and the mechanisms are integrated with systems such as a large data platform. By adopting the scheme of distributed data storage, the capacity, maintainability and safety of data can be comprehensively considered, and the existing enterprise-level distributed storage solution, such as a data warehouse, a database cluster and the like, is supported to be used for storing multi-trust node data.
Privacy protection: although the multi-trust node technology has certain anonymity, the sending and receiving addresses and the money amount are traceable, and the privacy is obviously lacked for some industrial applications such as financial applications. Therefore, the reconciliation platform considers the following data to be subjected to careful encryption processing. The transaction identity is anonymous, and the transaction double (multi) party address is completely anonymous in the transaction, so that the requirements of one-time pad, unforgeability, no relevance and traceability are met. Encrypting the transaction data, and encrypting and transmitting and storing the transaction data. And encrypting the account state, and transmitting and storing the account state data in an encryption manner. For the encrypted data, the condition that interest-relevant parties (counterparties and monitoring parties) have the right to see plaintext data and other participants have no right to see plaintext data is met, but the authenticity of ciphertext data can be verified, and the platform plan realizes multi-level privacy protection. And identity anonymity is realized, the group signature is used for identity anonymity, and meanwhile, a supervisor can track the identity of the user. Data privacy protection, additive homomorphic encryption algorithms that have been implemented on clients and smart contracts, is intended to add zero knowledge proof to prove the correctness of encrypted data (e.g., whether account balance data is sufficient for payment). Fine-grained authority control, multi-level access control based on an attribute encryption algorithm and a proxy authorization cryptographic algorithm, is used for controlling privacy access to encrypted data.
As shown in fig. 2, the reconciliation process of the reconciliation system based on distributed data nodes mainly includes:
s1: the payment system uploads the transaction flow and the fund flow to the distributed nodes for reconciliation;
s2: the partner can inquire the reconciliation result, and if the reconciliation result is inquired, the original data can be obtained from the distributed nodes;
s3: the creation of the distributed nodes can be realized by a distributed database, and the distributed node system adopts an open source system: the GlusterFS is used as a storage system, and all transaction parties can upload transaction flow and fund flow through the HTTPS;
s4: acquiring account checking files from upstream channels (financial institutions such as banks and unions of unions), and analyzing programs line by line and warehousing;
s5: in the process of program processing, taking the table of the upstream reconciliation file as a reference, reading the program line by line, comparing the program line by line with the transaction record of the system, comparing the program line by line with the accounting record (in the case of an accounting system, the reasonable scheme is to be the accounting record), and finding out a difference record;
s6: and taking the transaction record and the accounting record of the reconciliation system as a reference, reading the transaction record and the accounting record by the program line by line, comparing the transaction record and the accounting record with an upstream reconciliation file, and finding out a difference record.
Specifically, different differences exist in bill interface downloading forms, bill data formats and the like of each channel, if the bill data are completely stored according to the original bill format of a third party, the subsequent bill data processing logic is relatively complex, and when a new payment channel is added, a bill storage table needs to be newly built according to a channel bill structure, so that the development workload is increased, and an unreasonable situation exists. In order to implement the uniform formatting of the bill data, the original bill files of each channel need to be uniformly and standardizedly converted, and a relatively universal channel bill data table needs to be designed to store the formatted data of bills of different channels, and the specific structure is as follows:
in addition, in order to improve efficiency during bill data storage, the standard bill file format needs to be designed to be consistent with the table structure, so that the file load/copy can be directly loaded into the database after data conversion is completed, and the speed is much higher; considering that the data size will grow very much, this table can also be stored in Hive, but for most of the company's transaction volume, there will be some technical implementation cost to do so, and it is the Postgresql database (version 9.5.4) that is used as the bill repository.
In addition, the download logic of the bill also needs to consider the anti-repeat logic, that is, the bill data of the same day of the same channel account cannot be repeatedly downloaded and put in storage, so that besides storing specific bill data, a bill download record table also needs to be designed for storing the download condition of the channel account in the same day, and the anti-repeat download logic judgment is carried out according to the table when the bill download task is started. It should be further noted that, when the original bill and the standard bill are downloaded, because the read and write of the bill files are local disks, unified file storage service, GlusterFS file storage, or a folder sharing service built by itself is required for unified and centralized management of the bill files and data security.
The original bill file and the download position of the standard bill file also need to be stored in the bill download record, so that the original bill file and the download position of the standard bill file are basically not used at ordinary times, and the original bill file is only conveniently searched and reloaded when the original bill file needs to be retrieved in order to be conveniently used for data problem troubleshooting in the future.
The core reconciliation logic of the reconciliation system based on the distributed data nodes is that after the bill downloading task of the corresponding channel is completed, the system can start the reconciliation task of the corresponding channel according to the characteristics of each channel and the scheduling logic of the task system of the reconciliation platform, for example, a WeChat bill starts to be downloaded at about 10 points, the predicted completion time is within 10 minutes, then the reconciliation task of a third party can be scheduled to start to be executed at 11 points, and so on, the reconciliation time point of each reconciliation channel is determined according to the actual condition of the reconciliation channel.
Generally, when reconciliation is performed with a third-party payment channel, a platform order number is used as a correlation condition, full join is performed on data in an account list and data in a payment platform order list to obtain a set total, and the obtained set can be an intersection and two complementary sets. The data set description in the intersection part can be corresponding according to the order number, but the order amount comparison is needed, if the data set description is consistent, the order amount comparison is conducted, no error is indicated, the bill data and the platform order data service field complete set are taken from the flat data set according to the settlement data requirement, the account checking detail table is directly generated, and if the data set description is inconsistent, the error data with the error type of 'amount inconsistent' is required to be generated and recorded in the account checking error data table.
The complement set on the side of the bill data belongs to a long error, that is, the data exists in the third party bill, but is not found in the payment platform order success data set, and the reason of the error data may be a cross-day transaction situation, or an order drop on the system level, which will be explained in detail later in error processing.
The complement set on the side of the payment platform order belongs to a short-payment error, namely the part of data exists in the successful order of the payment platform but does not exist in the bill at the time of channel account checking, so that the reason of the part of error is possibly caused by the cross-day transaction condition or the settlement error of a third party, and the specific reason needs to be processed according to different conditions in the design of error processing logic.
The bill data table and the payment platform order table are full join, but since the bill table is stored in Postgresql and the database adopted by the payment system may be Mysql or Oracle, in short, from the viewpoint of system splitting, reconciliation processing and online payment orders are generally not put in one library, even if it is unwise to directly relate the bill table and the payment order table in one library, on one hand, the stability of the real-time payment system may be affected, and in addition, the data of the tables are increased, and the reconciliation data query is slowed down along with the accumulation of the data.
Therefore, when checking account of a certain channel, the bill data and the order data of the payment platform need to be respectively cleaned into two intermediate tables which are respectively called a bill to-be-checked intermediate table (A table) and an order to-be-checked intermediate table (B table) according to conditions, and then full join operation is carried out through the two tables, so that the account checking logic can not affect other services, meanwhile, the data can be regularly cleaned after the account checking task is finished at the end of a day, and the data scale of the intermediate tables is ensured to be in a controllable state.
If the data of the result set is large, the system does not adopt a Spark + Hive mode, the query needs to be paged through a traditional programming mode, the number of data can be obtained slightly by one page, for example, 5W data are obtained at one time, then the data set is divided and processed in parallel in the system by adopting a multithreading mode, each thread is executed according to a specific reconciliation logic, and after a reconciliation detail result set or an error result set is obtained, the result set is stored in a reconciliation database in batch.
In consideration of the completion of account checking and the processing errors involved later, the result is that account checking detail data is generated, the account checking detail data is the most accurate fund data behind a channel vs platform, and the method has great significance for subsequent merchant clearing, fund clearing and settlement, so that the frequency of complex query is higher, the use time range of the data is larger, the annual payment data volume of a company with larger transaction volume can reach the scale of billions, and in the aspect of data storage, the method can consider that a distributed relational database such as TIDB is adopted to store the data related to the account checking result, so that the logic efficiency of subsequent data processing is improved greatly. People may ask why the Hive is not directly used for query, because the single query and the batch query of the Hive are the same in efficiency, and therefore the Hive is not suitable for real-time query, and if account checking, settlement and other data need to be managed through a management system, the related query scenes are more, so that comprehensive consideration of using a distributed relational database is more suitable.
After the execution of the reconciliation logic of the reconciliation system based on the distributed data nodes is finished, reconciliation error data which cannot be matched by the system in the execution process of a part of reconciliation logic is generated, the part of data is recorded in a reconciliation error information table after the reconciliation is finished, the error information table records the detailed information of the error according to the error type, and the error information table can classify the error and define a specific error type code besides key information such as channel type, money amount, transaction time and the like.
Errors can be roughly classified into three types according to different situations: long, short, wrong. The long money can be divided into two conditions of channel success, platform order absence, channel success and platform state non-success according to different reconciliation processing modes, from the production practice, as a plurality of payment failure orders exist in the payment system, and the bill data of successful payment of a user can be provided under most conditions of bills of domestic payment channels, the cleaning of the intermediate table A and the intermediate table B is the order data which is considered to be successful by both parties when the reconciliation is actually carried out, the long money type generated under the condition only has the type of channel success and platform order absence.
For short payment, the bill data of the current day is not matched, and the error type is 'platform success, bill data do not exist'. The condition of inconsistent money is relatively rare, and mainly occurs to the condition that the money of the order of the payment platform is inconsistent with that of a third party when the WeChat and Payment treasures carry out marketing activities; in addition, when partial refunds to the order exist, if the order model of the payment system does not satisfy the situation well, the situation that the reconciliation amount is inconsistent can also occur.
For different error types, a corresponding processing flow needs to be designed according to the actual situation of the system. For example, for a long fund error, the reason for the long fund error needs to be identified, if the long fund error is caused by the cross-day transaction, for example, the time of the transaction on a platform is 23:59:59 seconds of a certain day, the time of the transaction sent to a third-party channel may already be 00:00:01 seconds of the second day, so the reconciliation on the first day may generate a short fund error, and at this time, only the error needs to be eliminated and the corresponding reconciliation detail needs to be generated. If the payment platform state is not successfully processed, the problem of system bill drop is caused, besides normally eliminating the error and generating corresponding reconciliation detail data, the payment system needs to be informed to perform state updating operation, the related business logic needs to trigger merchant callback according to the flow design of the whole payment platform, or the accounting system needs to be informed to perform reimbursement operation.
Data consistency among systems is guaranteed by combining the flow of the whole payment system according to specific error types and reasons, and the following general processing flow for long errors is as follows:
as shown in fig. 3, firstly, it is determined that the money is a money error, after the determination, the payment order table is inquired, whether the order exists is determined, if the order does not exist, the order is determined to be an online test order, and a payment system order replenishment interface is invoked to initiate a transaction reimbursement operation; if the order exists, further judging whether the payment order state is successful; if the payment order state is an unsuccessful state, informing a payment system of order compensation by using a payment bill problem, carrying out logic processing by the payment system, initiating transaction additional accounting operation and sending a merchant order payment result notice; and if the payment order state is a success state, inquiring whether the reconciliation detail exists, if so, eliminating the long-money error, updating the detail settlement time to be the bill issuing time, if not, judging whether a corresponding short-money error record exists, if so, eliminating the long-money and short-money records in a cross-day transaction manner, and if not, eliminating the long-money error record in a cross-day transaction manner.
In the above money process flow, the distinction regarding the cross-day transaction situation: after the payment order state is judged to be successful, whether the condition of account checking detail exists or not is judged before whether the short payment error matched with the payment order state exists in the same time of T-1 day or T-N day or not is judged, and the reason is that the real-time performance of order settlement is considered during system design, and a T +1 day processing mode is allowed to be adopted for the short payment error.
As shown in fig. 4, the short error general processing flow:
firstly, determining that the short payment is wrong, checking whether account checking details exist or not, judging whether account checking is repeated or not, and if the account checking is repeated, processing the account checking in long payment processing of T +1 and T + N to eliminate the short payment error; if the account checking detail does not exist, judging whether the account checking detail exists in the historical bill data, if so, generating the account checking detail according to the bill data and eliminating short-payment errors; if the status is not in the historical bill data, whether the status is successfully inquired through a channel payment order inquiry interface is judged, and if the status is not successful, manual verification and manual hedge are carried out; and if the state is successful, generating reconciliation detail elimination error data according to the error information and the query result, and setting the settlement time of the reconciliation detail channel as normal transaction time + 1.
The reconciliation system based on the distributed data nodes utilizes the distributed multi-trust node technology to branch the reserve payment transaction information into nodes, ensures the reality and transparency of data to be traceable, solves the reconciliation problem of a payment system and a partner, reduces the labor and time cost of the partner, improves the timeliness and the accuracy of the reconciliation, is very suitable for the scenes of transaction data synchronization, reconciliation and the like in the financial industry, and solves the problem that the traditional batch file reconciliation mode cannot be solved for a long time.
The above detailed description merely describes preferred embodiments of the present invention and does not limit the scope of the invention. Without departing from the spirit and scope of the present invention, it should be understood that various changes, substitutions and alterations can be made herein by those skilled in the art without departing from the spirit and scope of the invention as defined by the appended claims and their equivalents. The scope of the invention is defined by the claims.
Claims (9)
1. An account reconciliation system based on distributed data nodes, comprising: the distributed node is used for butting payment systems of transaction parties, and is provided with:
the file acquisition module is used for downloading or reading the reconciliation files of all channels;
the file analysis module is used for creating different analysis templates and acquiring the corresponding analysis template according to the channel and the file type for analysis;
the account checking processing module is used for the business logic processing of account checking;
and the error processing module is used for processing the orders in the error pool.
2. The account reconciliation system based on the distributed data nodes as claimed in claim 1, wherein the file acquisition modes of the file acquisition module include active acquisition, opposite side pushing and manual uploading, the active acquisition triggers the operation of downloading the file at a fixed time point every day through a timing task, the active acquisition has a retry mechanism, and the operation of re-downloading the file can be performed under the condition that the file downloading fails.
3. The reconciliation system based on the distributed data node as claimed in claim 2, wherein the file type parsed by the file parsing module includes, but is not limited to, EXCEL, TXT and CVC, the file parsing module parses and then uniformly converts the bill data and order data of different channels and stores the parsed and converted bill data into a general bill data table, the bill data table defines different data ends and assigns corresponding fields to the different data ends and fills the fields into the table, the bill data table is stored by using a GlusterFS file, and the bill data table is stored on a Postgresql database.
4. The reconciliation system based on the distributed data node as claimed in claim 3, wherein the file acquisition module is provided with an anti-duplication mechanism, and the anti-duplication mechanism is used for judging whether repeated downloading and warehousing conditions exist in the process of downloading the reconciliation file.
5. The reconciliation system based on the distributed data node of claim 3, the reconciliation processing module compares the billing data with the payment order data after acquiring the billing data table, the reconciliation processing module respectively cleans the bill data and the payment order data into a bill to be reconciled intermediate table and an order to be reconciled intermediate table, then, SQL full join operation is carried out on the two intermediate tables to obtain a set total, the set comprises an intersection and two complementary sets, and the data sets in the intersection part are consistent in order amount comparison, which indicates no error, and (4) directly generating a reconciliation detail table by combining bill data taken from the flat data set according to the settlement data requirement and a platform order data service field complete set, and if the bill data are inconsistent, generating error data, recording the error data in the reconciliation error data table and moving the error data table into an error pool.
6. The distributed data node-based reconciliation system of claim 5, wherein the reconciliation data processed by the reconciliation processing module is stored by a TIDB distributed relational database.
7. The reconciliation system based on the distributed data node as claimed in claim 5, wherein the error information table records the detailed information of the error according to the error type, including but not limited to channel type, amount, transaction time, classifies the error, defines a specific error type code, and classifies the error into: long, short, wrong.
8. The distributed data node-based reconciliation system of claim 7, wherein the processing of the long error comprises manual reconciliation, tie-out, or automated processing.
9. The reconciliation system based on the distributed data node as claimed in claim 7, wherein the system operated by the distributed node adopts an open source system, adopts GlusterFS as a storage system, and each party of transaction uploads transaction flow and fund flow through HTTPS.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111477685.5A CN114169887A (en) | 2021-12-06 | 2021-12-06 | Reconciliation system based on distributed data nodes |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111477685.5A CN114169887A (en) | 2021-12-06 | 2021-12-06 | Reconciliation system based on distributed data nodes |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114169887A true CN114169887A (en) | 2022-03-11 |
Family
ID=80483373
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111477685.5A Pending CN114169887A (en) | 2021-12-06 | 2021-12-06 | Reconciliation system based on distributed data nodes |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114169887A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115984022A (en) * | 2023-03-17 | 2023-04-18 | 梅州客商银行股份有限公司 | Unified account checking method and device for distributed payment system |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110188136A (en) * | 2019-06-10 | 2019-08-30 | 四川长虹电器股份有限公司 | A kind of modularization reconciliation system and its account checking method based on bank-corporate express |
| CN110765091A (en) * | 2019-09-09 | 2020-02-07 | 上海陆家嘴国际金融资产交易市场股份有限公司 | Account checking method and system |
| CN111429264A (en) * | 2020-03-25 | 2020-07-17 | 中国工商银行股份有限公司 | Combined account checking method and device for distributed system |
| CN112862578A (en) * | 2020-12-14 | 2021-05-28 | 苏宁消费金融有限公司 | Account checking system and device |
-
2021
- 2021-12-06 CN CN202111477685.5A patent/CN114169887A/en active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110188136A (en) * | 2019-06-10 | 2019-08-30 | 四川长虹电器股份有限公司 | A kind of modularization reconciliation system and its account checking method based on bank-corporate express |
| CN110765091A (en) * | 2019-09-09 | 2020-02-07 | 上海陆家嘴国际金融资产交易市场股份有限公司 | Account checking method and system |
| CN111429264A (en) * | 2020-03-25 | 2020-07-17 | 中国工商银行股份有限公司 | Combined account checking method and device for distributed system |
| CN112862578A (en) * | 2020-12-14 | 2021-05-28 | 苏宁消费金融有限公司 | Account checking system and device |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115984022A (en) * | 2023-03-17 | 2023-04-18 | 梅州客商银行股份有限公司 | Unified account checking method and device for distributed payment system |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10783116B2 (en) | Systems and methods for managing data | |
| US10698795B2 (en) | Virtual payments environment | |
| Wang et al. | Inter-bank payment system on enterprise blockchain platform | |
| CN108600148B (en) | Transaction message processing method and device | |
| CA2905996A1 (en) | Fraud detection and analysis | |
| US20200334671A1 (en) | Encrypted and authenticated message services | |
| WO2018237264A1 (en) | System and method for implementing an interbank information network | |
| US11068473B1 (en) | Scalable and advanced analytics computing platform for distributed ledger data | |
| CN114445010B (en) | Block chain-based multi-mode intermodal system and method | |
| US20190108586A1 (en) | Data ingestion systems and methods | |
| US20140089156A1 (en) | Addresses in financial systems | |
| US20210333995A1 (en) | Data block-based system and methods for predictive models | |
| US20220075892A1 (en) | Partitioning data across shared permissioned database storage for multiparty data reconciliation | |
| CN102208061A (en) | Data cancel after verification processing device and method | |
| Ekici et al. | Data cleaning for process mining with smart contract | |
| CN114169887A (en) | Reconciliation system based on distributed data nodes | |
| US11570005B2 (en) | Systems and methods for proving immutability of blockchains | |
| KR20210068039A (en) | Context-based filtering within a subset of network nodes implementing the trading system | |
| US10564849B2 (en) | Data compression technologies for micro model advanced analytics | |
| EP3794543A1 (en) | Automatic inter-bank reconciliation system | |
| CN113643032B (en) | Information processing method, device and data management system based on block chain | |
| CN112269829B (en) | Block chain data management method based on resource recovery system platform | |
| CN109120411B (en) | Asset securitization basic asset data collection method and device | |
| US20230030421A1 (en) | Systems, methods, apparatuses and computer program products for executing data verification operations between independent computing resources | |
| TWI831114B (en) | Integrity verifying method, system and computer device of separated cross-platform trade and accounting, computer-readable medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |