One fraud data vocabulary to rule them all.
Feb 20, 2024 🕒 2 min read
As engineers, managers, and directors building fraud tooling in retail, e-commerce, and fintech companies, you know the struggle: every fraud integration speaks its own data language.
First, you have to deal with data inputs required by your fraud integrations.
Transaction Fraud Example
One wants "transaction.customerEmail", another demands "customer.email", and a third throws a curveball with a list of associated emails. Transaction amounts? Some assume USD while others demand a currency field. Major units (eg 5.00 = $5.00) are the norm for some, minor units (eg 500 = $5.00) are the required format for others.
Account Takeover Example
One integration wants an address, another wants latitude and longitude, and another tries to determine location from an IP address. Device fingerprints? Some integrations might create their own fingerprint requiring a frontend SDK. Others might leverage an internal ID, create a fingerprint based on input data, or use something else to simulate a fingerprint.
Second, you have to deal with outputs.
Integrations have very different ways of returning a risk score or output. Common examples: 1-100, 1-1000, "very_high", "low", a list of risk factors, or a net-new data type like a boolean of whether or not an SSN is associated with a deceased person. Each type of returned data may be formatted in different ways, and your response might change depending on any combination of factors from any number of sources.
Navigating this inconsistency for every fraud type becomes a maintenance and testing nightmare.
But fear not! There' a solution: Dodgeball's Standardized Fraud Vocabulary.
Imagine a single source of truth for common fraud inputs and outputs. This is Dodgeball's vocabulary, a unified structure that translates your source data to any integration's language needs. No more deciphering cryptic field names or wrestling with incompatible formats. We handle the translation of this source data to an arbitrary list of integrations.
Benefits for Busy Engineering Leaders:
Dodgeball does the heavy lifting:
Say you need to send a transaction amount to a fraud integration. Dodgeball's vocabulary simplifies it:
Dodgeball then translates this into the format the integration expects, whether it's:
Currency
{ amount: 500 }
{ amount: 5.00, currency: "USD" }
{ minorUnits: 500, currencyCode: "USD" }
Dodgeball takes the guesswork out of data formatting, freeing you to focus on what matters most: building robust fraud detection systems.
Ready to tame your fraud data? Check out Dodgeball Docs for the full vocabulary and see how it can streamline your fraud tooling development. Remember, less data wrangling means more time for innovation!