TrustSphere Vendor Assessment: Salv, and the Case for Treating Information Exchange as Infrastructure


The single most reliable structural advantage a fraudster holds over a bank is that they operate across institutions while the bank operates inside one. A mule chain is designed around that asymmetry. Funds land in an account at bank A, move within minutes to bank B, split across accounts at two electronic money institutions, and settle at a cryptocurrency exchange. Every institution in that chain sees a fragment. None of them sees the chain. The fraudster does, because they built it.
The formal remedies for this are real and they are slow. Suspicious activity reporting, law enforcement requests, court orders and inter-bank recall processes all work, and all operate on timescales measured in weeks, while the funds move in minutes. The gap between the speed of the criminal network and the speed of the official channel is the single largest recoverable loss in payment fraud, and it is a process problem rather than a detection problem.
Salv exists in that gap. It is not a detection engine and does not present itself as one. It is a network and a legal framework that allows participating institutions to ask each other direct, structured questions about specific accounts and transactions in near real time, under a pre-agreed basis for doing so. That is an unglamorous proposition, and it is one of the few controls in this market whose value is easy to demonstrate in an afternoon.
Score and Capability Profile
Salv scores 6.4 out of 10 in the TrustSphere RiskTech Index 2026, against an index mean of 6.06, in the Cross-Institutional Intelligence Sharing category within the Data Sharing and Collaborative Financial Crime cluster. The capability profile is deliberately lopsided: Enterprise Fraud Risk Management 8, Fraud Detection 7, Transaction Monitoring and Screening 6, Client Lifecycle Orchestration 6, Watchlist and Sanctions Screening 5, eKYC and KYB 4, Device Intelligence 2, Behavioural Biometrics 2, Document Authentication 2.
The shape of that profile is more informative than the composite. The three lowest scores (Device Intelligence, Behavioural Biometrics, Document Authentication) all measure the ability to observe a customer directly at the point of interaction, and Salv does none of that. It has no view of the device, the session, the typing cadence or the identity document. Those scores are not weaknesses in execution; they are a description of what the product is not, and a buyer who penalises them has misunderstood the category.
The high scores sit where the product actually operates. Enterprise Fraud Risk Management at 8 reflects that the strongest use case is the investigation and case management layer, where an analyst holding a partial picture needs the missing part of it quickly. Fraud Detection at 7 and Transaction Monitoring at 6 reflect a monitoring and rules capability that is competent and useful, particularly for institutions building from a thin base, but which is not the reason to buy. Client Lifecycle Orchestration at 6 reflects the ability to route shared intelligence into onboarding and periodic review decisions rather than leaving it in the fraud team.
A 6.4 sits modestly above the mean, and that placement is honest. This is a narrow product assessed on a broad scale. Institutions that buy it as a platform will be disappointed by the breadth. Institutions that buy it as a network will find the composite score understates it considerably in the markets where the network is dense.
What It Actually Does Well
The core capability is real-time bank-to-bank information exchange, and the demonstration that matters is tracing a mule chain. An analyst holding a fraudulent inbound payment can ask the receiving institution what happened to the funds, receive a structured answer, follow the next hop, and repeat, compressing what would otherwise be a sequence of formal requests spanning several weeks into a single working session. That is not a marginal improvement in analyst productivity. It changes which cases are recoverable at all, because funds that are still sitting somewhere can be frozen and funds that have gone cannot.
The second genuine strength is the legal and operational framework rather than the software. Participating institutions have already signed the arrangements that permit the exchange, agreed the data fields, agreed the permitted purposes and agreed the response expectations. That framework is the expensive part of the problem, and it is the part that institutions consistently underestimate when they consider building bilateral arrangements themselves. Two banks that want to share information can, in principle, negotiate it directly. In practice they will spend eighteen months in legal review and produce something that covers one counterparty.
The third strength is the structure of the exchange. Informal queries between fraud teams already happen over email and telephone, and they are slow, inconsistent, unauditable and legally uncomfortable. Converting that into a defined request type with a defined response, a logged audit trail and an agreed purpose limitation is a compliance improvement as much as an operational one, and it is why this can be presented to a supervisor as a control rather than as an unmanaged practice.
The fit against job and task scams, which is today's theme, is unusually direct. That typology produces victims who are simultaneously senders at one institution and receivers at another, and the two halves of the evidence sit in two different banks. A rapid exchange between them is the only mechanism that reliably converts a suspected mule at the receiving bank into an identified recruitment victim, and identifies the deposit victim at the sending bank as part of the same operation.
Where the Limitations Are
The most important limitation is that value is a direct function of network density in the specific market concerned, and headline membership counts are close to meaningless as a proxy for it. What matters is whether the institutions the criminals actually use are members. Mule chains in 2027 do not terminate at large retail banks; they run through electronic money institutions, payment institutions, neobanks and crypto-asset businesses, precisely because those are the segments with the fastest onboarding and the thinnest membership in collaborative arrangements. A network with impressive coverage among incumbent banks and weak coverage among electronic money institutions will trace a chain to the point where it becomes interesting and stop there. Buyers should require coverage data by institution type and by market, and should treat that data as the primary evaluation criterion, ahead of every functional consideration.
The second limitation is that this is a sharing layer and not a detection engine, which produces a quiet asymmetry in the network. An institution with weak detection will simply share less. It will receive queries and answer them, because answering is a data lookup, but it will originate few useful alerts because it does not identify much in the first place. That matters for two reasons. It means the buying institution must be honest about whether its own detection is good enough for the network to amplify, and it means the network's overall value depends on the detection maturity of its weakest significant members, which no purchaser controls.
The third limitation is the lawful basis for sharing, which varies by jurisdiction and is the most common reason implementations stall. The question is not whether sharing is permitted in the abstract; it is whether this specific institution, in this specific market, can share this specific data field for this specific purpose, and can evidence that determination to its own data protection officer and to a supervisor. Some jurisdictions have express gateways for fraud and financial crime information sharing. Others rely on legitimate interests assessments that a conservative legal function will not sign. In engagement work this is where projects die, and it dies late, after commercial agreement and before go-live, because the legal review is treated as a formality until it is not.
The fourth limitation is a conduct risk rather than a technical one, and it deserves to be stated plainly. Shared intelligence about a customer can be used to protect that customer or to exclude them, and the second is easier, cheaper and organisationally more tempting. An institution that receives a signal that a prospective customer appeared in another member's mule investigation can use it to apply enhanced monitoring, or it can use it to decline the application. The typologies most relevant here, job scams and coerced mule recruitment, produce exactly the population most likely to be wrongly excluded: young, recently arrived, financially inexperienced and deceived. Purpose limitation must be designed into the governance from the start, with documented rules on which shared signals may inform an adverse decision and which may only inform monitoring. Networks that do not enforce this will eventually produce a supervisory problem for every member.
Questions to Press in the Demo
The demonstration will show a chain traced quickly, and it will be genuine. The questions that matter are about coverage, latency, legal footing and governance, none of which are visible in a demonstration and all of which determine whether the control works in production. Press for numbers and documents rather than assurances.
What is your member coverage in our specific markets, broken down by institution type, and specifically what proportion of the electronic money institutions, payment institutions and crypto-asset businesses that receive mule funds from our customers are members?
What is the median and ninetieth percentile time to a substantive response, measured per member rather than as a network average, and what happens operationally when a member does not respond?
Which jurisdictions do you regard as having a settled lawful basis for the exchange we are proposing, which rely on a legitimate interests assessment, and can you provide the reasoning that other members' legal functions accepted?
What technical and contractual controls prevent a receiving member from using shared intelligence to decline or exit a customer rather than to monitor them, and how would a member's misuse be detected?
If our own detection is weaker than the network average, what do we contribute, and can you show what a member with our alert volume actually receives in return?
Verdict
Salv's 6.4 is a fair mark for a product whose value is almost entirely determined by something the vendor only partly controls. Where the network is dense in the segments that matter, it converts a category of loss that was previously written off into a category that is sometimes recoverable, and it does so through a legal and operational framework that is genuinely expensive to build alone. Where the network is thin in electronic money and crypto, it produces fast answers to the easy half of the chain and silence at the point where the money actually left.
The institution that should buy this is one with competent detection, a real mule problem, a fraud investigation function that is limited by information rather than by analytical capacity, and a legal function willing to do the work on lawful basis early rather than late. The institution that should not buy it is one hoping that a sharing layer will compensate for weak monitoring, because it will not; it will simply publish the same gaps to a wider audience. This pairs naturally with a strong transaction monitoring and behavioural capability that generates the signals worth sharing, and it should be governed jointly by fraud, financial crime and data protection from the first workshop rather than the last.
Suggested Next Steps
Require coverage data by institution type and market, with explicit figures for electronic money institutions, payment institutions and crypto-asset businesses, and make it the primary selection criterion.
Commission the lawful basis assessment before commercial negotiation concludes, and treat data protection sign-off as a gating milestone rather than a closing formality.
Define a written purpose limitation policy specifying which shared signals may inform adverse decisions and which may inform monitoring only, and build the technical controls to enforce it.
Run a controlled trial on a sample of recent mule cases, measuring recovery outcomes and time to trace against the existing formal channel, and quantify the benefit before scaling.
Sources: Financial Conduct Authority guidance on financial crime systems and controls and information sharing; UK Economic Crime and Corporate Transparency Act information sharing provisions; National Crime Agency guidance on money mule networks; European Banking Authority guidelines on money laundering and terrorist financing risk factors; AMLA and the EU anti-money laundering package provisions on information exchange; Wolfsberg Group principles on effectiveness and information sharing; Financial Action Task Force guidance on public and private sector information sharing; TrustSphere Risk Index, April 2026.
TrustSphere helps financial institutions design and deploy intelligent fraud and financial crime detection solutions. Visit www.trustsphere.ai



Comments