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.

The Problem

Parsing Data Inputs

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.

Parsing Data Outputs

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.

Solution

One Fraud Data Vocabulary to Rule Them All

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:

• Reduced complexity: Focus on core fraud logic, not data wrangling.
• Simplified maintenance: Changes in one place propagate seamlessly.
• Faster testing: Consistent data formats streamline testing efforts.
• Improved efficiency: Spend less time on data translation, more on innovation.

Dodgeball does the heavy lifting:

• Translation engine: Translates your data to the specific needs of each integration.
• Visual workflow editor: Process both standard and custom outputs with ease.
• Powerful analytics: Gain deeper insights into fraud patterns and trends.

Let's dive into an example:

Say you need to send a transaction amount to a fraud integration. Dodgeball's vocabulary simplifies it:

• Send: Transaction amount (transaction.amount) in minor currency units.
• (Optional) Specify the currency (defaults to USD).

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!