There is a flaw in fraud detection methods employed by the
payment industry today: too many false positives. How many transactions pop up
as potentially fraudulent, receive human inspection, and may receive human
rejection, without any proof whatsoever of a consumer intending to commit
fraud.
On the other hand many fraudsters learn that by creating
transactional data that does not set off normalcy meters, their fraudulent transactions receive approval
without going anywhere near a human eyeball. Yet there are elements within message that shows prima facie
fraud, meaning you could bring the message into court and just the message, and
gain a conviction of fraud from the consumer that caused the origination of the
message. The difficulty with the
approach is the haphazard collection and discard of data that occurs while a
transaction message is in-flight.
For example, say a store operates at an address and a
purchase message arrives from a point of sale (POS). The acquiring node tossed
the address associated with the phone number once the needle created a circuit;
however that address may have nothing to do with the POS operational address.
If the two addresses are not the same, then it is possible to say fraud exists because
a party to the transaction created the message from a place not known to the authorizer.
I define machine examination of disparate data maintained in
the entire set of transactional data (not just data associated with a part of
the journey) as a filter. Millions of potential filters exist but fraud
detection engines do not use any of them, because the prejudice to use
deviations from known behavior, or newness of a card initiator, waste enough
time, without tracking and pulling transactions that contain data that confirms
fraud without false positives.
The fraud detection filters have a companion. Evasion
detection filters capture transactions deliberately created to evade fraud detection
filters and the two filters together create a dialectic response to the cycle
of criminal activity. They also show when filters fail because they are too
well known by the attacker class.
Next Blog: Find
out tomorrow, or response to comments, or is there a demand for payment escrow
accounts?
No comments:
Post a Comment