COOPERATIVE FRAUD-DETECTION PROCESSING
A portion of information is cryptographically hashed to obtain a hash value. The hash value is submitted as a search to shared cryptographic cooperatively shared transaction data structure and results are obtained for previous transactions associated with the information. A decision is made as to whether a pending transaction for the information is to be submitted to a host for processing or whether the pending transaction is to be denied before the information is provided to the host.
1 . A method, comprising:
calculating a hash from identifying information of a payment instrument;
submitting the hash as a search to a cooperatively shared transaction data structure;
obtaining results in response to the search; and
determining one of: whether to provide a transaction to a host for processing, whether to deny the transaction without sending the transaction to the host based on the results, and whether to accept the payment instrument as acceptable payment for the transaction when hosts are unnecessary for payment.
2 . The method of claim 1 further comprising, updating a status for the transaction after receiving an acceptance or a denial when the transaction is provided to the host for processing within the cooperatively shared transaction data structure.
3 . The method of claim 2 further comprising, providing selective transaction information for the transaction with the hash and the status for inclusion in the cooperatively shared transaction data structure as a unique transaction record.
4 . The method of claim 2 further comprising, updating the status for the transaction after subsequently receiving an indication that a chargeback was made on the transaction within the cooperative shared transaction data structure.
5 . The method of claim 1 , wherein calculating further includes hashing a payment instrument number and an expiration date for the payment instrument producing the hash.
6 . The method of claim 1 , wherein submitting further includes providing the hash as a key for obtaining records as the results from the cooperatively shared transaction data structure that identify prior transactions made with the payment instrument at a plurality of different merchants.
7 . The method of claim 1 , obtaining further includes obtaining the results as prior transaction information for prior transactions made with the payment instrument at a plurality of different merchants.
8 . The method of claim 7 , wherein determining further includes applying customized merchant-specific rules against the prior transaction information for deciding whether to provide the transaction to the host or whether to deny the transaction without sending the transaction to the host.
9 . The method of claim 1 , wherein determining further includes processing the determining in real time for the transaction when the payment instrument is presented as payment at a Point-Of-Sale (POS) terminal for the transaction.
10 . The method of claim 9 , wherein determining further includes processing the determining in real time as a pre-processor for an existing payment process of the POS terminal.
11 . The method of claim 1 , wherein determining further include processing the determining in real time as a plug-in to a web-based transaction interface that is processing the transaction.
12 . The method of claim 11 , wherein determining further includes processing fraud rules that are specific to a merchant that is to be credited should the host receive the transaction for processing.
13 . A method, comprising:
providing an Application Programming Interface (API) for maintaining a cryptographically and cooperatively shared transaction data structure between multiple different merchants;
adding transaction records from transactions to the cryptographically and cooperatively shared transaction data structure when received from the merchants through the API; and
returning in real time selective transaction records to the merchants in response to hashes submitted as searches through the API to the cryptographically and cooperatively shared transaction data structure for pending transactions with the merchants.
14 . The method of claim 13 , wherein providing further includes maintaining the cryptographically and cooperatively shared transaction data structure as a private Blockchain or private acyclic graph that is collaboratively maintained by the merchants.
15 . The method of claim 13 , adding further includes updating statuses for particular transaction records when received through the API from the merchants within the cryptographically and cooperatively shared transaction data structure.
16 . The method of claim 13 , wherein returning further includes processing the searches as pre-processors to existing payment processing associated with the merchants that is activated through the API before the existing payment processing submits payment details to payment hosts for the pending transactions.
17 . The method of claim 13 , wherein returning further includes providing each selective transaction record as information that includes: a hash for a payment instrument account number, a transaction date and time, a transaction location, a transaction amount, and a transaction status, wherein the transaction status is a value selected from: accepted, declined, and chargeback.
18 . The method of claim 17 , wherein returning further includes excluding from each selective transaction record a full identification of the payment instrument account number.
19 . A system, comprising:
a server; and
an inter-merchant cooperative fraud manager;
wherein the inter-merchant cooperative fraud manager is configured to: i) execute on at least one hardware processor of the server, ii) maintain a cryptographic cooperatively shared transaction data structure between multiple different merchants, and iii) search the cryptographic cooperatively shared transaction data structure in real time for making decisions on whether to submit a pending transaction to a payment host for a payment decision or whether to decline the pending transaction without sending the pending transaction to the payment host.
20 . The system of claim 17 , wherein the pending transaction originates and is pending on one of: a web server, a Self-Service Terminal (SST), a Point-Of-Sale (POS) terminal operated by a clerk of one of the merchants, a mobile device, a network-voice enabled appliance, and a device that is part of the Internet-Of-Things (IoTs).