How a fintech platform scores every user email 0-10 with ZeroBounce at onboarding, turning a throwaway address into an early fraud signal in its automated trust score.
Key findings
A fintech platform scores every user's email on a 0 to 10 scale at onboarding with ZeroBounce, then reuses that one number as a fraud signal for the life of the account.
The email score is one weighted input in an automated user trust score, alongside a business-records check, a phone-reputation check, and an IP-risk check.
The raw 0 to 10 number maps to five plain-English grades (Very Safe down to Very Risky) so a person triaging leads can act without reading a number.
The check is one background API call per sign-up and is deliberately fail-open: if ZeroBounce is unreachable, onboarding still completes.
The largest trade-off: a missing score counts as zero, which silently drags a user's trust score down rather than flagging the email as unknown.
When a user signs up, the email they type is the first thing you learn about them, and a throwaway, mistyped, or high-risk address is a quiet warning sign. This is a look at how a fintech platform turned that signal into something automatic: every onboarding email gets scored by ZeroBounce, and that one number feeds both an automated trust score and a human-readable risk grade. The writeup covers what gets scored, where the number is used, how it behaves across real sign-ups, and where the design makes deliberate compromises.
What does ZeroBounce actually score?
ZeroBounce returns a single number from 0 to 10 that rates how trustworthy an email address is, combining two things: whether mail can be delivered to the address at all, and whether the address carries a reputation for abuse or risk. Per ZeroBounce's own documentation, its AI scoring endpoint rates an address that has not yet received a message, so it works at sign-up before any email has been sent.
A real, long-lived work address scores high. A disposable address created minutes ago, an obvious typo, or an address tied to past abuse scores low. That single number is a cheap, fast read on the person behind the sign-up, which is what makes it useful as a fraud signal rather than just a deliverability check.
It helps to separate two related jobs email vendors do. Plain email validation answers "will this bounce?" Email scoring, the job used here, answers the softer question "how much should I trust this address?" The platform cares about the second question, because a fraudster's throwaway inbox is often perfectly deliverable - it just should not be trusted.
Why does a user's email matter for fraud?
A user's email matters because it is self-reported, unverified at the moment of entry, and strongly correlated with intent. The platform onboards users who type in their own address, with no guarantee it is real, theirs, or anything they mean to keep. A throwaway or high-risk email frequently travels with a low-quality lead or an outright fraud attempt.
The cost of ignoring that signal is human time. Agents and managers end up chasing sign-ups that were never going to convert, or worse, were never genuine in the first place. The platform needed a way to tell, automatically and at the exact moment of sign-up, which emails look trustworthy and which deserve a second look - without slowing onboarding down and without blocking a real person over a service hiccup.
Email is a good early signal precisely because it is available before almost anything else. A business-records or phone check needs more information and more time; the email is there on the first screen. Scoring it early means a suspicious onboarding can be flagged before an agent has spent a minute on it.
How does the platform score an email at onboarding?
The platform sends the user's email to ZeroBounce during onboarding and stores the returned score against the user record. From there the number does two jobs: it feeds an automated trust score, and it is translated into a plain-English grade a person can read at a glance.
One email score, captured once at onboarding, fans out to the trust score, a human-readable grade, and the team's tools.
The integration is a small, self-contained service with a single job. It exposes one method that takes an email and returns either a numeric score or nothing at all. The credentials it needs are loaded from a secrets store at start-up rather than hard-coded, and the whole thing is wired so a failure never bubbles up into the sign-up flow.
// The shape we care about from the scoring response.interface ZeroBounceScore { score: number; // 0-10, higher means more trustworthy}@Injectable()export class ZeroBounceService { private readonly logger = new Logger(ZeroBounceService.name); constructor( private readonly http: HttpService, private readonly config: ConfigService, // apiKey + baseUrl loaded from SSM at boot ) {} /** One job: return a 0-10 score, or null on any failure (fail-open by design). */ async getEmailScore(email: string): Promise<number | null> { try { const { data } = await firstValueFrom( this.http.get<ZeroBounceScore>(this.config.get('zeroBounce.baseUrl'), { params: { api_key: this.config.get('zeroBounce.apiKey'), email }, }), ); return typeof data.score === 'number' ? data.score : null; } catch (err) { // A ZeroBounce outage must never block onboarding: log and move on. this.logger.error(`ZeroBounce scoring failed for ${email}`, err); return null; } }}
Two design choices are worth calling out. First, the score is captured once, at onboarding, and is not recalculated later when other user details change. Second, the API key is loaded asynchronously from a secrets store (AWS Systems Manager Parameter Store) when the service boots, so the key is never committed to the codebase and can be rotated without a redeploy. AWS Systems Manager Parameter Store is the managed home for that kind of configuration and secret.
How does a 0-10 score become a decision a human can act on?
A raw number from 0 to 10 means little to someone triaging leads, so the platform maps it to a grade anyone can act on. The five bands turn a continuous score into a short vocabulary - Very Safe, Mostly Safe, Cautiously Safe, Slightly Risky, Very Risky - plus a sixth "No data" state for when no score exists.
The raw 0-10 score maps to five plain-English grades, plus a separate "No data" state when scoring returned nothing.
The grade is what actually reaches people. A number invites a follow-up question ("is 6 good?"); a label does not. This small translation layer is what lets a non-technical agent glance at a lead and know whether to lean in or slow down, and it is why the score earns attention instead of sitting unread in a database.
How much does the email score weigh in the overall trust score?
The email score is one ingredient in a larger automated trust score, contributing one weighted input, not the whole verdict. The composite blends four independent checks: a business-records check (the heaviest input), the ZeroBounce email score, a phone-reputation check, and an IP-risk check. Each is normalized and weighted, then summed into a single figure that ranks how much automated confidence the platform has in a new user.
In practice the email score contributes its weight in proportion to the 0-10 rating. A perfect 10 from ZeroBounce lands the full contribution; a 5 lands half; a 0, or a missing score, contributes nothing. Because the inputs are independent, a bad email drags the composite down on its own, which is exactly what surfaces a suspicious onboarding for review even when the other signals look ordinary.
Keeping email's weight modest rather than higher is deliberate. Email is a strong signal but a noisy one - a legitimate founder might sign up with a brand-new domain that scores low. Capping its influence means a single soft signal cannot sink a genuine user by itself, while a cluster of weak signals across the four checks still adds up to a clear flag.
Where does the score show up for the team?
The score and its grade follow the user into the tools the team already uses, so nobody has to go looking. They appear in the internal lead view, they sync to the CRM as a readable note such as "8 - Mostly Safe," and they show up as a column in lead exports. (CRM here means the customer-relationship-management system where the sales team works leads.)
Surfacing the grade in three places covers three different work styles: the lead view for someone triaging in the app, the CRM note for someone living in the sales pipeline, and the export column for someone slicing a spreadsheet. The point is that a low-quality address becomes visible in the normal flow of work rather than requiring anyone to query a database or read a raw API response.
How does it behave across three real scenarios?
The design is easiest to understand through the sign-ups it was built for. Three cases cover the range.
Scenario 1: a clean corporate email
A user signs up with a long-established company domain. ZeroBounce returns a 9, the grade resolves to Very Safe, and the email check contributes its full weight to the trust score. Nothing interrupts onboarding; the signal simply reinforces the other checks, and an agent triaging the lead sees green and moves on quickly. This is the path most sign-ups take, and it is meant to be forgettable.
Scenario 2: a disposable or mistyped address
A sign-up arrives from a throwaway inbox or an address with an obvious typo. ZeroBounce returns a low score - say a 2 - which maps to Very Risky and contributes zero points. On its own that will not block the account, but it pulls the composite trust score down and paints the lead red in the CRM. An agent now has a concrete reason to slow down and verify before investing effort, which is the entire purpose of scoring the email early.
Scenario 3: ZeroBounce is unreachable, or there is no email
If the scoring call fails, times out, or the user provided no email at all, the service returns nothing and onboarding continues uninterrupted. The event is logged, the stored score is left empty, and the grade shows "No data." This is the fail-open behavior working as intended: a third-party outage or a missing field should never be the reason a legitimate user cannot sign up. The trade-off this creates is covered next.
What are the risks and gotchas?
The design makes several deliberate compromises, and knowing them matters for anyone auditing the trust score or extending the integration.
Fail-open means "unknown" looks like "worst." When scoring fails, the score is absent, and absent is treated as zero in the trust math. That keeps sign-up resilient, but it means a ZeroBounce outage silently lowers every affected user's composite score rather than flagging those users as "score unavailable." During a provider outage, a wave of genuine users could look riskier than they are. An audit reading the trust score after the fact cannot tell a real 0 apart from a failed call unless it also reads the logs.
The score is captured once and never refreshed. It is computed at onboarding and not recalculated when user details change later. If an email is updated after sign-up, the stored score can go stale. Re-scoring on change would close that gap but was left out to keep the integration simple.
Only the headline number is kept. ZeroBounce returns more than the score - a status, a sub-status, and sometimes a suggested correction for an obvious typo - but the platform stores only the final 0-10 figure. That discards signal that could improve triage (for example, distinguishing "disposable domain" from "full mailbox") and cannot be recovered without re-querying.
Rate limits and cost scale with sign-up volume. One call per onboarding is cheap at current volume, but a spike in sign-ups - organic or from a bot attack - drives a matching spike in API calls. Because the call is fail-open, a rate-limit rejection degrades gracefully to "no score" rather than an error, which is safe but again masks a real problem behind a silent zero.
What would we do differently?
The single most valuable change would be to distinguish "unknown" from "risky." Storing a small status alongside the score - scored, no-email, or scoring-failed - would let the trust score exclude failed calls from the math instead of treating them as zero, and would give auditors an honest picture. It is a small schema change with an outsized effect on trustworthiness of the composite.
Beyond that, two enhancements are natural: persisting ZeroBounce's richer fields (status, sub-status, suggested correction) so triage can act on why an address scored low, and re-scoring on email change so the signal cannot go stale. The integration already works as a fraud signal; what these add is auditability - the ability to say why a score is what it is, and to trust it hasn't gone stale.
Frequently asked questions
What is the difference between email validation and email scoring?
Validation answers whether an email will bounce - is the mailbox real and reachable. Scoring answers a softer question: how much should you trust this address, factoring in abuse reputation and risk. This integration uses scoring, because a fraudster's throwaway inbox is often perfectly deliverable but should not be trusted.
Does a low email score block a user from signing up?
No. A low score never blocks onboarding on its own. It contributes to an automated trust score and shows up as a risk grade for a human to review, but the decision to slow down or reject a user stays with people and the composite signal, not with the email score alone.
What happens if ZeroBounce is down during sign-up?
Onboarding continues. The scoring call is fail-open: if it errors or times out, the service returns nothing, the event is logged, and the user's grade shows "No data." The trade-off is that a missing score is treated as zero in the trust math, so an outage can make genuine users look riskier until it is resolved.
How much does the email score influence the trust score?
It is one of several weighted inputs, and deliberately capped. The composite blends four independent checks - business records, the ZeroBounce email score, phone reputation, and IP risk - with email weighted below business records. The cap keeps a single noisy signal from sinking a legitimate user.
Is the email re-scored if the user changes their address later?
Not currently. The score is captured once at onboarding and not recalculated when details change. Re-scoring on change is a known enhancement that would prevent the stored score from going stale, but it was left out to keep the integration simple.
Does the platform store the full ZeroBounce response?
No. Only the final 0-10 score is kept. Other fields ZeroBounce returns - status, sub-status, and any suggested typo correction - are discarded, which keeps storage simple but loses signal that could sharpen triage later.
The email score does one well-defined job today: a quick, trustworthy read on a user's address at the moment they sign up, one weighted input in the automated trust score. The clearest next step is honesty about uncertainty - separating a failed call from a genuine zero - followed by keeping ZeroBounce's richer fields and re-scoring when an email changes. For now the integration stays focused on the single signal that earns its place in the trust score.
