How might DQ affect Fraud
One area of interest to them is customers or use cases revolving around FRAUD. I could’nt quite pinpoint the best way to showcase this (other than Source to Target DQ checks)
Is there a good use case or customer working with CDQ in a Fraud Capacity? Or if there isnt one = what’s the best way to make that link// bridge that gap (if we can)
ericgerstner
Posted 4 years ago · Edited 1 year ago·Last reply 4 years ago
1 comment
ericgerstner
OP4 years ago · EditedI would say that Fraud is just like any other Root Cause for anomalies in Data. Something is amiss, we presume it’s a bad ETL or inadvertent code.
What happens when it’s a mal actor?
What makes CDQ better than your typical rules engine?
Consider the advantages of CDQ amidst typical institutional internal controls for fraud.
Perhaps a use case to share:
When “Behaviors” notices data drift as rows disappear from our cookie marketing data, our 3rd party vendor may not be sharing everything.
When “Outliers” shows lower BW executions in a regional report for internet connectivity, we might have someone misappropriating BW.
When “Patterns” notices that IP Address X is logging in from location in another continent, we might have a fraudulent login.
When Source does not match the target DB, we could detect malicious changes in previous data.
When Schema notes a brand new column that appears to be joining all PII, we could be seeing a SQL analyst trying to collect organization information.
When Dupes shows rows with fuzzy matches on emails,we could be seeing a robot process meant to overwhelm our login service.
When Shapes see a unique email format, we could be seeing mal actors leveraging a specific domain enter our ISP.