I recently joined Jerry Hoff, CEO of AppSec Training, for a Blueprint Series session on fraud signal sharing, and it’s a topic I keep coming back to. Fraud, trust and safety, and security teams often work from separate systems with no shared view of the same bad actor. That gap slows response time and lets repeat offenders move across teams undetected. Here’s what I’ve learned building signal-sharing programs across internal teams and vendors.
Signals are useful far beyond the fraud team
At its core, a signal is any piece of information that helps a program do its job: PII, IP addresses, device data, activity patterns. Signal sharing is what happens when you take that same data and put it to work in more than one place.
Within fraud teams, you use signals for prevention and investigations. But those same signals help security events and other teams’ initiatives too. I’ve worked with IT and security teams who want visibility into fraud trends, and legal and compliance teams who need data specifically for law enforcement requests. I’ve also seen it used more strategically for growth, sharing data with commercial teams, marketing, and customer support. A lot of what fraud and trust and safety teams see is either useful elsewhere in the business, or it’s the same problem another team is watching through a different lens. Everybody is so focused on their own program that it’s easy to forget how useful this data is across the business. It just takes real strategic effort and buy-in from leadership to make it work.
Most teams still share informally, and that’s the point of failure
When we polled the live audience, about 43% said they share fraud signals over Slack or email threads, 30% use a shared dashboard or report, and 30% don’t share at all. That tracks with what I’ve seen. Shared dashboards and reports can be as simple as a CSV file going back and forth, and dashboards are better because multiple teams get one central place to look. Slack and email are great for quick interactions, but they’re not built for cross-team functionality or transparency across an org.
I’ve watched signal sharing start to work and then deteriorate more times than I’d like to admit. Early in my career, at a web hosting company, we tried to share fraudster data across the wider industry, meeting with leaders at competitors who were excited at first. But it only really benefited a few players in the group. The companies it wasn’t helping backed away or stopped submitting anything, and within a few months we tabled the whole effort.
It definitely takes people being bought in, having champions of that initiative and process, and being willing to ask honestly whether it’s working, and if it is, how to make it better.
The lesson is to map which signals matter to each function, get a key of definitions everyone can reference, and agree on a short list to focus on rather than trying to boil the ocean.
Without a shared KPI, sharing is optional
We asked whether fraud teams share a KPI with any other department or vendor, and about half said no, they operate independently. That’s real room for improvement. Every fraud practitioner knows this tension. Your job is to drive down loss and mitigate risk to the business, but you also care about growth and company success.
Having a shared KPI, something as simple as a suspension rate, where there’s a goal across teams you’re trying to hit and a balance you’re trying to strike, is where you start to unlock growth and alignment across the company.
Without that alignment, you’re just doing activity for activity’s sake, and it leads to deterioration or an unsuccessful program. A shared metric, whether it’s a suspension rate, a false-positive rate, or a detection-speed target, gives multiple teams with different incentives a reason to keep the pipeline healthy instead of letting it quietly go stale.
Trust and liability concerns are the real blocker, not tooling
When we asked the audience what blocks signal sharing most, trust and liability concerns came out on top, ahead of leadership not prioritizing it, no shared owner, and data format mismatches. That tracks with my own experience. Some organizations are strict about this, and they’ll say they’re not going to give access to certain data, or they’ll give it to you hashed or anonymized. Legal teams tend to err on the side of keeping things private and secure, while teams that want to move fast will share things in a way that’s still trusted, but quicker. Add international data transfer questions into the mix and it gets even more complicated.
There’s always a way to get this done, whether through tooling, user groups, or permissions. But I understand why trust and liability concerns are top of mind for everybody.
Vendors need to be part of the loop, not gatekeepers of it
This one is hard to get right. Practitioners want to make their programs better, and often that means pulling signals from multiple vendors and making sense of it all. Vendors need to understand that’s a real thing practitioners are trying to do. If we get too precious about how data can be used internally by the merchant, the conversation gets tricky fast.
My advice to practitioners is to have open and honest conversations with your account team at any vendor you work with. What are you trying to achieve and how? A lot of vendors are building some version of a data-sharing layer into their products now. Done well, that keeps things trusted and proprietary while still giving practitioners what they need to do their job.
Measure engagement, not just dashboards
If you have alignment on KPIs and goals, that’s a good sign things are working. But there’s a more intangible signal too, engagement. If the other team or vendor you’re sharing with goes quiet, that’s usually an indicator something’s off.
I ask whether certain metrics, like detection speed and suspension rate, are improving over time, and whether bad debt is getting driven down by what we’ve put in place. I look at both the traditional KPIs you share with your partners and whether the trust is being maintained and the sharing process is still being iterated on.
Making the case for investment
When Jerry asked me to sum up how to build the business case for signal-sharing investment, my answer was short. Show that it matters. Come in with data, show where the potential is for savings or for growth, and that goes a long way with your organization.
If there’s one thing I want practitioners to take from this, it’s that signal sharing breaks down for people and incentive reasons far more often than technical ones. A short list of prioritized signals, a named owner, a shared metric, and a habit of checking whether the other side is still paying attention will outlast almost any dashboard.
