Smartnumbers is a fraud intelligence company serving telecommunications and financial institutions. The platform connects fraud intelligence across organisational boundaries — transforming isolated call data into actionable insight. With hundreds of thousands of fraud decisions captured, Smartnumbers helps investigators detect and prevent fraud in real time, before funds leave the business.

I noticed a pattern through a continous discovery framework I built... Fraud investigators at different banks often have intelligence on the same fraudster without knowing it. Cross-bank sharing meant a human picking up a phone, taking days, and often never happening at all. Each bank's data was rich, but siloed, and compliance had no framework for a shared view. Fraud moves in hours; the system moved in days, if it moved at all.

I owned discovery, UX strategy, interaction design, design system components, and the compliance-safe information architecture, embedded with product and engineering as the only designer on the team, not a handoff role.

It started with a question: what if a meaningful share of fraudsters appearing in one bank's data were also appearing in another's?

I taught myself enough Python to run cross-tenant queries against live data across four banks, and found that 52% of fraudster profiles had crossover across institutions. That number became my internal stakeholder stat. It reframed the conversation from "maybe we should share intelligence" to "here is the scale of what we're currently missing."

Buy-in didn't come quickly. It took six months to get full alignment, because the compliance and legal implications were significant. The turning point was external: industry signals started pointing toward cross-institution information sharing becoming the expected direction. Because we'd already done the analysis and groundwork, we were positioned to move as soon as that window opened.

Alongside the data work, I scheduled calls with fraud investigators across banks to understand what intelligence they'd actually be willing to share, and where the legal and psychological boundaries sat. The key finding: investigators wanted to collaborate; confidence, not willingness, was the barrier. They didn't know what they could legally share.

The compliance team was clear: free-text data shared across organisations was a risk under data protection regulations. One stray field — a name, a card number or an address — and the bank holding it would be liable.

That confidence gap investigators described is exactly why a fixed schema mattered: not to be restrictive, but to give investigators a vetted set of shareable fields so they didn't have to guess their legal exposure. The standardised schema also fed downstream data science work cleanly, without forcing any bank to change its internal taxonomy.

Canonical identity across tenants

Each bank referred to the same fraudster differently internally. I designed a consortium-level canonical name and relationship graph that sat above tenant data. Without it, the crossover I'd found in the data would never surface in the product.

All of the information an organisation has on a fraudster that is PII compliant.

A fixed schema, chosen with users

I ran three schema options with investigators and recommended the one that balanced speed of input against standardisation, making cross-bank intelligence queryable without forcing any bank to rebuild their internal systems.

Scoping out voice clips, deliberately

Investigators asked for the ability to share voice clips. We were building a text-only signalling layer, not a case management system, and legal restrictions on cross-organisation audio meant supporting it would have ballooned compliance risk for a feature that wasn't core to the value proposition. We kept the product focused on names, relationships, and structured call notes, staying launchable and not promising what we couldn't safely deliver.

The scope was large enough that releasing everything at once would have taken months, and demand was already there. I sliced the work into five incremental releases: structured fraud-type input first, then a cross-network activity feed, then call history and timelines per profile, then consortium chat, then API automation pushing data to downstream prevention systems. Each slice delivered standalone value while building toward the full platform.

I designed the intelligence-tagging flow around the ideal analyst workflow: add intelligence per individual record, per call. In reality, investigators spot patterns across batches of calls and wanted to tag a fraudster once and apply it across many records at once. We launched without that bulk-apply flow, and adoption of the intelligence layer stayed low because the entry point was too granular.

The signal wasn't subtle: support tickets piled up and customer satisfaction feedback was consistent. I used that to scope and design the bulk-apply flow and presented it to the Product Manager as the next priority. It was designed, but deprioritised against other work, and I left before it shipped. The lesson stuck: design for the workflow people actually have, not the one that's easiest to build first, and anchor priority calls in surfaced user pain, not roadmap convenience.

Designed and scoped from real support-ticket evidence, deprioritised before I left, but the right call was clear.

• Map batch workflows before optimising individual screens
• Surface compliance constraints during feature definition, not at review
• Give investigators' local intelligence labels parity with consortium views, to preserve their existing mental model