WO2020039173A1 - Transaction system and method - Google Patents

Abstract

A transaction system, method, and a computer program product comprising a server element and a cloud element, wherein a transaction involves a chain of parties. The customer is a first party in a transaction chain and a number of intermediaries are subsequent parties in the transaction chain. A platform runs on the server element, wherein the platform is accessible to the customer and a number of intermediaries. The customer or a first intermediary uses the platform to create a main entry on a blockchain, which main entry is stored in the cloud element. The main entry comprises an encrypted version of information relating to the transaction and other information and is identified by a hash function. Each of a second and subsequent intermediaries accesses the main entry using the hash function and adds a supplementary entry to the main entry before a subsequent intermediary accesses the main entry. The supplementary entry comprises an encrypted version of supplementary information and the supplementary entry is identified by another hash function.

Description

TRANSACTION SYSTEM AND METHOD

Field of Invention

The invention relates to a transaction system, in particular, to a system for use in a cross-border and/or multi-party transaction involving a chain of parties. The invention, more specifically, relates to the 'Know Your Customer’ (KYC) aspect of a transaction and the data gathering, verification, storage, sharing and recording required for KYC. The invention runs multiple automated simulations to generate individual risk scores for KYC verification for the customers and utilises blockchain’s distributed ledger to store sovereign identities of customers’ customers. The system also facilitates all the intermediaries to execute national and international business transactions on a secure and streamlined platform.

Background of the Invention

Fiscal risks including but not limited to financial crimes, fraudulent transactions and money laundering are still highly prevalent across global financial institutions, especially with cross-border and/or multi-party transactions. To mitigate all such risks, financial institutions need to perform risk assessments to gain insights about their customers, their customer’s financial business and their customer’s transactional beneficiary. However, the processes to collect such information in widespread use today are time-consuming, require frequent manual intervention and are highly error-prone.

Average customers’ on-boarding time for financial institutions increased by 22% in 2016, followed by 18% in 2017. 51% of global Financial institution respondents mentioned an exponential increase in engagement with regulators after the KYC introduction. 17% reported a "significant increase”. In the last decade, FSOs have paid US$26 billion as fines/penalties for not adhering to local KYC regulations. 85% of customers consider KYC verification a bad experience because of its time- consuming nature and 12% of customers migrated to a different Financial institution claiming shorter KYC verification. The FCA’s first-ever financial crime report based on 2017 activity by over 2,000 firms, found that Financial Services Organisations handled 923,000 reports from their staff related to suspected money laundering, and refused to provide services to 1.15 million prospective customers for reasons related to financial crime. Firms also reported that they employ 11,500 full-time equivalent staff in financial crime-related roles and spend a collective £650m annually on compliance-related activity by staff.

Therefore, a need for a more efficient and thorough system/process exists.

Know Your Customer (KYC) is the general term used by institutions for the critical and mandatory tasks that the concerned parties must apply to establish a business relationship. This requires the parties to apply due diligence measures for a comprehensive evaluation of the identity and business activities of their customers to identify and manage all the probable financial crime(s) and reputational risks arising. Full KYC or enhanced due diligence includes sub-processes that go deeper, such as Know Your Customer’s Customer (KYCC), Know Your Customer’s Business (KYCB) and know your Customer’s Customer’s Business (KYCCB). In certain transactional models, such as cross-border and/or multi-party payments, the layers go even further and this requires a deeper level of verification.

The current platform for Worldwide transactions is the peer-to-peer network SWIFT. This lacks the required security for fund transfer and demands unwanted man hours as it acts as a telecommunication messaging service between banks associated with the SWIFT network. Each financial organisation operating on the SWIFT model is defined by a weak 8-11 character code, deeming the system vulnerable to fraudulent or criminal behaviour (s). Rather than the continued monitoring of the whole transaction flow, the current SWIFT model performs random test sampling of the transactions to mitigate risk. Without an automated or semi-automated comprehensive KYC system, it is difficult to ascertain all business, customer and transaction-related risks. Currently, many of the world’s leading financial institutions, using a model like SWIFT, have to decline international transactions that are associated with multiple financial and non-financial parties due to the potential risks involved. These financial institutions are terminating thousands of facilities (accounts) that involve such transactions, oftentimes leaving the customer without recourse.

Therefore, a need exists in the field of KYC, and related areas such as Anti-Money Laundering (AML) and Anti-Terrorist Financing (ATF) where a comprehensive automated system helps coordinate inter-institutional and inter-departmental risk- management tasks and provide the necessary features to identify and mitigate risks. The benefits of the automated workflow include, but are not limited to, improved verification speed, improved process accuracy, overarching visibility, convenient interoperability and overall granular accessibility in a credible and reliable automated ledger.

WO 2018/081698-A1 discloses systems and methods for the application of distributed ledgers for network payments as financial exchange settlement and reconciliation. The disclosed system/method implements a distributed ledger on a peer-to-peer network to store confirmed and unconfirmed transactions. The instruction of payment from the originator bank is posted on a distributed ledger on a peer-to-peer network, and the payment beneficiary also posts the payment instruction to the distributed ledger on the peer-to-peer network. If the payment instructions are equivalent, the transaction is validated and processed by the originator bank, by debiting the originator's account. This model acts as a secure messaging service, using a distributed ledger (e.g. blockchain) on a peer-to-peer network (e.g. SWIFT).

US 2018/0152304-A1 discloses a system and method for verifying the identity of a user using blockchain. The disclosed system/method manages user identity to improve security over current identity applications such as CHIP and PIN, password protection and security/challenge questions. Personal data that identifies the user, such as a passport or driver's license is uploaded, encrypted, processed through hashing functions and stored in a public storage facility (blockchain). A public key of a certification entity, corresponding to a hash value, a timestamp and a transaction number, provides the user certifiable data to the certification entity. The certification entity is configured to access the public storage facility to verify the user. A private key allows the user to decrypt the certifiable data to recover the hash value and then retrieve the hash value from the public storage facility. If the hash values do not match the user is not certified.

The prior art lacks the efficiency and accuracy of imperative security protocols for multiple institutional (cross-border) transactions, and the required multi-level certification and rejection interventions.

Summary of the Invention

The invention provides a transaction system comprising a server element and a cloud element, wherein a transaction involves a chain of parties. A customer is a first party in the transaction chain and a number of intermediaries are subsequent parties in the transaction chain. An online platform runs on the server element, wherein the platform is accessible to the customer and the number of intermediaries. The customer or a first intermediary uses the platform to create the main entry on a blockchain which is stored in the cloud element. The main entry comprises an encrypted version of the details of the transaction and other details and is identified by a hash function. Each of the second and subsequent intermediaries accesses the main entry using the hash function and adds a supplementary entry to the main entry before a subsequent intermediary accesses the main entry. The supplementary entry comprises an encrypted version of supplementary details and is identified by another hash function. The main entry is on a parent chain of the blockchain and the supplementary entry is on a side chain of the blockchain. For instance, the main entry may be KYC information for the customer. Each intermediary has access to the information to assess the KYC information. Each intermediary may add further KYC information in the form of supplementary entry for subsequent intermediaries to assess.

Within the transaction system, each second and subsequent user may apply a risk assessment to at least the main entry and, if the outcome of the assessment is negative, that fact may be added to the supplementary entry and the transaction chain continues, or, in the event that the outcome of the risk assessment is positive, the transaction chain may be broken. The risk assessment may be applied by the platform or by manual intervention.

The platform may control access rights to the main entry and/or a supplementary entry for each second and subsequent intermediary allowing access to transaction and/or other information The other information may comprise identity information or commercial information, and the personal information of the customer and each intermediary may be stored on a parallel chain.

The platform may provide a user interface locally for the customer and/or each intermediary, wherein the user interface may facilitate uploading and verification of documents and may integrate with a customer and/or intermediary user interface.

The invention comprises a platform for performing thorough KYC operations, where a sequence of participants in a financial transaction uploads sets of scanned documents required for the mentioned KYC processes. To improve customer experience, as another microservice, an omnifont, multi-linguistic and multi-device compatible Optical Character Recognition (OCR) tool converts the contents of scanned documents into text. It facilitates instant and convenient digital onboarding of the customers on the platform while reducing error rates because of manual data entry. The system also includes auto-transcription for images, documents, invoices, compliance reports, custom clearances and other documents shared by individuals and/or companies with the ledger.

Deep Learning/Machine Learning algorithms integrated into the invention keeps evolving with the qualitative and quantitative data fed to the ledger thereby enhancing its overall efficiency to perform more accurate OCR and digital transcriptions. The data collected from OCR and digital transcriptions are then sent to the platform as meta-data of the concerned individual or company’s docket which is then subjected to automated verification and validation functions, with provisions to accept or decline the transacting party or the individual transaction at any point, according to custom sets of rules as defined by the advanced due diligence compliance requirements.

The verified documents along with the credentials of the verifier get converted into a digital asset with a unique 32 -byte ID, which acts as a gateway to progress further into the sequence of approvals required by the system and its rules. The platform is equipped with intelligent features such as; continuous outdated (stale) documentation detection, automated reminders to the participants to upload up-to- date documents, and compliance and financial-crime monitoring engines that screen transactions against having any sanctioned participants and/or suspicious activity. The system also controls and logs access to KYC information and is fully General Data Protection Regulations (GDPR) compliant.

The invention is positioned as an automated system that can perform KYC tasks in a simpler, cheaper, faster, more efficient and secured model as compared to the currently prevalent methods. This system provides banking and non-banking financial institutions and other organisations with the necessary requirements to know their customers and manage their specific associated risks, dramatically improving their risk management processes. The present system also works in tandem with the various institutions’ existing transactional framework. In other embodiments, the system can be applied to any document that third parties require to be verified, as the case may be.

Brief Description of the Drawings

FIG. 1 shows a simplified block diagram of users accessing a cloud storage element via a server element.

FIG. 2 shows a simplified transaction flow within the KYC_BLOCK, from creator to approver.

FIG. 3 shows a simplified block diagram of a client application.

FIG. 4 shows a simplified block diagram of a network application working in tandem with a client application.

Detailed Description

A transaction, such as, for example, a purchase of goods by a customer from a seller, may involve a chain of parties. The customer may be a first party in the transaction chain and the other parties may be intermediaries, such as banks or other financial institutions, which are required to fulfil the transaction. In addition to intermediary banks required to handle, for instance, the electronic transfer of funds, the customer and the seller could be in different countries with different home currencies, which could mean further intermediary financial institutions would be required for the currency conversion aspect of the transaction. As aforementioned, each intermediary is required to know its customer, which means it must know not only the immediately preceding party in the transaction chain but also the parties further back in the chain.

With reference to FIG. 1, a transaction system 100 may comprise a server element 102 and a cloud element 101. A secure online platform runs on the server element. Each of the intermediaries 103 in a transaction chain and possibly the customer may connect to the server using a secure connection, such as a Virtual Private Network (VPN). For the purposes of this description, we will just refer to an intermediary being a user 103, although the user could also be the customer. When connected, each intermediary is provided on a local terminal with a user interface. Where, for example, the user is a bank which has an existing transaction system with its own user interface, the new user interface may integrate with the existing user interface. Through the integrated user interface, each intermediary can take part in the transaction, including being able to access KYC information and to make a risk assessment of the transaction based on the information.

Using the interface, a first intermediary can upload details of a transaction, such as information about the customer, the seller, their businesses, their locations, what is being purchased and the currency of the transaction. The first intermediary can also use the platform to upload documents for KYC purposes, for identification and verification of the customer, such as passports, trading information and accounts or other commercial information. In addition, the first intermediary can upload its own identification and verification documents. All the uploaded documents are independently verified.

The first intermediary may not be able to fulfil the transaction on its own, say because it is in a different country to the seller and does not keep the seller’s home currency. As a consequence, it requires the assistance of a further, second intermediary, who may, say, have access to the appropriate currency. The second intermediary may purchase the currency from a third intermediary, and a fourth intermediary may be the seller’s home bank in its home country. Together, the intermediaries form the transaction chain required to complete the transaction.

Once the first intermediary has uploaded all the transaction(s), its KYC information and information regarding the second intermediary from which it requires assistance, it indicates via the user interface that a transaction request is complete, whereupon the platform encrypts the information and stores it on a blockchain on the server element 102. The stored information is identified by a unique 32 -byte hash function. The information is stored as a main entry on a parent blockchain. A request is generated, which is sent to the second intermediary, asking the second intermediary to participate in the transaction. Using the hash function, the second intermediary is able to access the stored information. The second intermediary can make a risk assessment on the stored information, based on which it takes a decision whether to participate in the transaction. The risk assessment may be performed by the platform according to parameters set by the second intermediary or may be done manually by a compliance officer (e.g. a Money Laundering Reporting Officer - MLRO) of the second intermediary. If the outcome of the risk assessment is negative, the second intermediary uses the platform to indicate its agreement to participating in the transaction, whereupon the platform encrypts supplementary information provided by the second intermediary, such as the second intermediary’s own KYC information and the subsequent intermediary in the chain from which the second intermediary requires assistance, and that supplementary information is added to the main entry on the parent blockchain. The supplementary information is stored on a side chain of the blockchain. The supplementary information has its own unique hash function. A request is sent to the subsequent intermediary and the subsequent intermediary goes through the same process as the second intermediary, albeit the platform may restrict access of the second intermediary to all the information. Access may be limited to only that part of the information that the second intermediary requires.

Each intermediary in the transaction chain goes through the same process, accessing the stored information and either agreeing to participate in the transaction, in which case that intermediary adds information to the blockchain, or, if the outcome of its risk assessment of other participants is positive, refusing to participate in the transaction, in which case the chain is broken.

For each intermediary in the chain, details are added to a private parallel chain, indicating their participation in the transaction. At any time in the future, these details may be deleted in the event any intermediary party requests anonymity.

The present invention comprises an online platform located on a secure online server 102 that allows easy and safe access to both customers and Financial Services Organisations 103 from where the mandatory KYC process is initiated, as outlined above. The technological platform to facilitate the assessment of the transaction is called KYC_BLOCK. Referring to the transaction flow within the KYC_BLOCK in FIG. 2, a financial transaction participant/user/creator 201 logs in to the online platform and uploads the required personal, corporate and transactional scanned documents (such as a passport) for KYC verification. Unclear documents are rejected at this point 201 and resubmission from the user is required. The submitted documents pass through two main validation processes; first validation by a trusted third party as to the authenticity of the document, and second by the participant(s) of the transaction. The second validation cannot be processed without the first validation being approved. Approval of the participants to a transaction proceeds to the validation of the transaction itself, based on custom sets of rules according to each jurisdiction’s laws, the institution’s "Risk Assessment Matrix” (RAM) and best practices guidelines.

The documents are transcribed within the KYC_BLOCK by a transcriber 202. The transcriber 202, being an Optical Character Recognition (OCR) and auto transcription tool, converts the contents of the scanned documents into text. This is more efficient and accurate than manual data entry. The transcriber 202, for example, takes an image of a customer’s passport that has been uploaded onto the system by the customer and produces a data set related to the image as a unique text. This is performed seamlessly as the only required customer input is the uploading of the passport image, making onboarding to the system easier and more convenient for the customer than current manual input methods. Also, the efficiency of the process is further enhanced as the transcriber 202 of the system has omnifont and multi-linguistic capabilities, meaning that any document in any language can be uploaded and shared within the ledger system between individuals and/or companies. In addition, the transcriber 202 is multi-device compatible making it easily accessible to any customer, individual or company from any country. The transcribing of the scanned documents also reduces the number of errors which is common when customers are manually inputting their security details. The present invention further comprises Machine Learning algorithms to improve the accuracy of the OCR and auto-transcriptions. The KYC documents uploaded by individuals and companies are stored on the blockchain, with the invention functioning as a secured data repository. The Machine Learning algorithm evolves as the qualitative and quantitative data, uploaded and stored on the blockchain, increases. The algorithm uses various document parameters to train the AI operation. The document parameters include but are not limited to individual country stamp, standardised document font, background image, layout, profile image, entropy and obliquity. These parameters can vary from one country to another. The Machine Learning algorithm can monitor the official document parameters and implement any proposed changes in government regulations over time. The Machine Learning algorithm enables the invention to extract recognized characters from the uploaded documents, be it embedded, printed or handwritten and convert them into machine-readable character streams. This is done automatically through the OCR and auto-transcription tool on upload of the documents, and automates the tedious task of manual transcription, data-entry and categorisation. The data collected from the OCR and digital transcriptions are then sent to the platform as meta-data of the concerned individual or company’s docket which is then subject to automated verification and validation functions. This automation of the uploading and transcription makes the overall process more convenient and faster, for all parties, while reducing the overall cost.

The documents can again be rejected at the transcribing stage 202 within the flow. Once transcribed 202 the data is added to a docket through a third-party API software 203 and checked for false positives. The documents/transaction are screened and then approved/rejected on all entities related to the transaction both manually by a Money Laundering Reporting Officer (MLRO) and through an IM Portal 204.

Each role in the various participation layers performing the multiple validation and verification functions in the above-described transaction flow 200 is defined and controlled as per a predefined process. The system has the built-in provisions to decline acceptance of the documents or transaction request at any point, be it a full and final rejection or a return for corrections/clarifications and re-submittal if needed. Otherwise, if accepted and validated, it will progress to the next step in the flow, which can be internal (within the financial institution) or external (with an intermediary or client). Thus, manual process to collect and verify documents is replaced by an automated system that takes a pre-scripted path, and distributes each task of uploading, transcribing and validating documents to each participant party, thereby lowering concentration of workloads, minimising possibilities of errors, and speeding up the overall end-to-end process, resulting in quicker transaction processing.

FIG. 3 illustrates one operation of the system where a client application is processed 300. The application 300 is a simple cross-border transaction. The international payment issuer, 301 is purchasing goods from the international payment recipient 302. In this instance, the international payment issuer (importer) 301 is a company in Peru, purchasing Belgian chocolates for€90,000. The Peruvian company has an account with a local bank 303 (an intermediary), in this case, Bank of Lima, who is a client of the wholesale financial services institution (WFSI) 304 (a subsequent intermediary). The importer’s bank is a client of the WFSI and holds an account with the WFSI that is denominated in USD and GBP. The company instructs the Bank of Lima 303 to make a payment on their behalf to the international payment recipient

302. The international payment recipient (exporter) 302 is a company in Belgium, manufacturing high-grade Belgian chocolates. The Belgian company has an account with a European bank 303 (an intermediary), in this case, ABN AMRO. The company raises an invoice for€90,000 and awaits confirmation from the customer in Peru that payment is forthcoming before shipment is made.

In this particular transaction, only two retail financial institutions (clients/users)

303, the exporter’s bank (ABN AMRO) and the importer’s bank (Bank of Lima) are involved but additional institutions may be included in the process. The Bank of Lima instructs the WFSI to make payment, debit their account in Peruvian Sol (S/) for the corresponding value in Euros, on behalf of their client to ABN AMRO. The WFSI plays the role of Custodian 304 by taking deposits from the Bank of Lima, and role of risk assessor by vetting all relevant documents to conclude this transaction is valid 100, and that the transaction is for genuine tangible goods. The WFSI also acts as the payment facilitator by ensuring the payment is made in accordance with the terms set forth by the exporter’s invoice.

Since the payment is due in Euros, the services of a licensed Foreign Exchange (FX) broker 306 (an additional intermediary) may be required in some instances by the WFSI. The FX broker can assist in providing in this case Euros for the onward transmission to ABN AMRO bank.

An independent document validation 305 is performed by KYC_BLOCK. All documents pertaining to the transaction including; Peruvian importer’s company filings, Bank of Lima’s registration and ownership documents, bio-data on all beneficial owners of the exporter and importer’s respective companies are all uploaded and stored on the blockchain within the KYC_BLOCK, as an embodiment of FIG. 2. Third party sanction screening on all entities related to the transaction, as well as AI-inspired risk assessment scores are generated for the transaction and submitted to the MLRO at the WFSI for final approval for the transaction.

FIG. 4 shows a simplified block diagram of the network application 400 working in tandem with the client application 300. The network application 400 receives the relevant documents and transaction information and is processed according to the KYC_BLOCK transaction flow 200. The documents and transaction information are stored by KYC_BLOCK in object storage such as AWS S3 Cloud Storage 101/406. After approval 405, all documents are processed by the KYC BLOCKCHAIN flow 401, where the physical information relating to the transaction, and all parties involved in the transaction, are converted into digital information by the security engine of the platform. The security engine performs encryption algorithms to convert the data into a unique 32 -byte ID (hash function) 402. This unique 32 -byte ID becomes the key to linking KYC data in the system to an external system. For example, a KYC BLOCKCHAIN system can use the unique ID to link transactions and store in a parent blockchain. The encrypted documents are subject to additional third-party verification 403 on all entities related to the transaction. Further customer risk assessment 404 is also performed before the data is approved and stored on the blockchain.

At any stage/level of the client and network applications, manual intervention within the system can occur, allowing the transaction to be cancelled/rejected, say due to a suspected fraudulent transaction or elusive goods. KYC_BLOCK can allow third parties to have access into the blockchain through specific public keys to view the identity of the client or part or all of the audit trail. KYC_BLOCK can provide selective views depending on the role of the assessor. Private side blockchains are used to store personal details, which an individual can request to be deleted, therefore adhering to GDPR laws. The system consists of two parallel data repositories, one original and one encrypted, within the S3 Cloud Storage 406. The encrypted data is primarily used to connect external systems such as KYC BLOCKCHAIN, whereas the original data is kept separately in a side-chain, with a new block created on the side-chain for each person/client/company. This arrangement allows the system to maintain compliance with extant regulations on data privacy, security, and deletion (GDPR).

The present model (FIG. 4) carries out the necessary KYC functions on all KYC processes and sub-processes on all transactions before any such transaction is processed, with manual intervention at any point along with the transaction flow. The platform consists of monitoring engines that use real-time analytics processes which determine the probability of authenticity and coherent nature of any transaction and actively rejects any suspicious transactions.

Claims

1. A transaction system comprising a server element and a cloud element, wherein a transaction involves a chain of parties, wherein the customer is a first party in a transaction chain and a number of intermediaries are subsequent parties in the transaction chain, wherein a platform runs on the server element, wherein the platform is accessible to the customer and a number of intermediaries, wherein the customer or a first intermediary uses the platform to create a main entry on a blockchain, which main entry is stored in the cloud element, wherein the main entry comprises an encrypted version of information relating to the transaction and other information and wherein the main entry is identified by a hash function, wherein each of a second and subsequent intermediaries accesses the main entry using the hash function and adds a supplementary entry to the main entry before a subsequent intermediary accesses the main entry, wherein the supplementary entry comprises an encrypted version of supplementary information and wherein the supplementary entry is identified by another hash function.

2. A system of claim 1 , wherein the main entry is on a parent chain of the blockchain and the supplemental entry is on a side chain of the blockchain.

3. A system of claim 1 , wherein the data collected is from Optical Character Recognition (OCR) and digital transcription tools, and sent to the platform as meta-data.

4. A system of claims 1 or 2, wherein each second and subsequent user applies a risk assessment to at least the main entry and, in the event that the outcome of the assessment is positive, that fact is added to the supplementary entry and the transaction chain continues, or, in the event that the outcome of the assessment is negative, the transaction chain is broken.

5. A system of claim 4, wherein the risk assessment is applied automatically by the platform or by manual intervention.

6. A system of any preceding claim, wherein the application controls access rights to the main entry and/or a supplementary entry for each second and subsequent supplier.

7. A system of any preceding claim, wherein the other information comprises identity information or commercial information.

8. A system of any preceding claim, wherein personal details of the customer and each supplier are stored on a parallel chain.

9. A system of any preceding claim, wherein the platform provides a user interface locally for the customer and/or each intermediary.

10. A system of claim 9, wherein the user interface facilitates uploading and verification of documents.

11. A system of claims 9 or 10, wherein the user interface integrates with a customer and/or supplier user interface.

12. A method of handling a transaction, wherein a transaction involves a chain of parties, wherein the customer is a first party in a transaction chain and a number of intermediaries are subsequent parties in the transaction chain, the method comprising running a platform runs on a server element, wherein the platform is accessible to the customer and a number of intermediaries, wherein the customer or a first intermediary uses the platform to create a main entry on a blockchain, which main entry is stored in a cloud element, wherein the main entry comprises an encrypted version of information relating to the transaction and other information and wherein the main entry is identified by a hash function, wherein each of a second and subsequent intermediaries accesses the main entry using the hash function and adds a supplementary entry to the main entry before a subsequent intermediary accesses the main entry, wherein the supplementary entry comprises an encrypted version of supplementary information and wherein the supplemental entry is identified by another hash function.

13. A platform or computer program product, which, when run on a server element, performs the method of claim 12.