TrustSphere Vendor Assessment: Sigma360, A Modern Decisioning Layer Looking for a Tier One Reference

Hero image: server-room-aisle-with-cable-management.jpg. An empty data centre aisle with neatly dressed cabling and indicator lights along a rack, photographed straight down the row with no individual in frame.

The screening estate inside most large banks was assembled between roughly 2005 and 2015 and extended ever since by addition rather than replacement. A list matching engine sits at the centre, surrounded by a workflow tool it was never designed to talk to, a data subscription it consumes as flat files, tuning parameters last justified in a document nobody can locate, and spreadsheets performing the entity resolution the engine cannot. It produces alerts and clears them within a service level. It is also expensive, slow to change, and structurally unable to answer the question posed in today's theme post: what authority a particular payment was released under, and whether that authority was still in force.

The category that has grown up in response calls itself risk decisioning: a data layer, an entity resolution layer and a configurable decision layer, sold explicitly against the incumbent stack. Its proposition is that screening is not fundamentally a string matching problem but a data and decisioning problem, and that a buyer who fixes the data and the resolution will do better than one who spends another cycle tuning fuzzy match thresholds. That argument is largely correct, and it is also the argument most likely to be oversold in a procurement.

Sigma360 sits in this category. Its platform covers sanctions, politically exposed person and adverse media screening, entity resolution across a broad set of public and licensed sources, customer risk scoring and ongoing monitoring, delivered through configurable decisioning rather than a fixed product workflow. The buying question is less whether the technology is good, which it broadly is, than whether the institution's risk and volume profile sits inside the envelope where that has been proven.

Score and Capability Profile

Sigma360 scores 6.5 out of 10 in the TrustSphere RiskTech Index, against an index mean of 6.06, in the category of screening and risk decisioning platforms. That is a good score for a challenger in a category dominated by entrenched incumbents, and the shape of the profile matters more than the number.

Taking the capability lines in order. Entity resolution and identifier quality scores 8, and is the strongest single line in the assessment. Data breadth, sourcing and coverage scores 8, as does politically exposed person and adverse media screening. Deployment speed and implementation effort also scores 8, on evidence that timelines are materially shorter than the incumbent comparators. Watchlist and sanctions screening scores 7, as do ongoing monitoring and event driven review, configurability and threshold governance, and integration and delivery. Model governance and explainability tooling scores 5, as do throughput, latency and scale at tier one payment volumes, and eKYC and KYB. Client lifecycle orchestration scores 4 and transaction monitoring scores 3. The combined enterprise fraud risk management, device intelligence and behavioural biometrics line scores 2, and the combined identity verification, liveness and document authentication line scores 2.

The weight vector is published so the arithmetic can be checked. Taken in the order the lines appear above, the weights are 11, 9, 9, 4, 13, 8, 8, 6, 9, 8, 5, 4, 3, 2 and 1 per cent. They sum to 1.00 and, applied to the scores above, produce a composite of exactly 6.50.

Two observations about the weighting. Deployment speed carries only 4 per cent deliberately: the index treats it as a benefit consumed once rather than a durable capability, and a platform bought for its implementation timeline will be regretted in year three. Model governance and explainability carries 9 per cent because in this category it determines whether the buyer can defend the system to a supervisor. The unweighted mean of the fifteen scores is 5.7, so the weighting works modestly in Sigma360's favour and the composite still sits less than half a point above the index mean. Read 6.5 as a strong, narrow platform with honest gaps rather than an enterprise financial crime suite.

What It Actually Does Well

The genuine differentiator is the data and entity resolution layer, and it is a real differentiator rather than a positioning claim. A legacy screening engine compares a name string against a list string and produces a score. A resolution layer builds an entity from many sources, reconciles identifiers, carries aliases and script variants, and then screens the entity rather than the string. The effect shows up in two places a buyer can measure: false positive volume at equivalent recall, and the analyst's ability to dispose of an alert without opening four other systems. Institutions replacing a legacy list matching engine are the natural buyer for exactly this reason.

The second strength is configurability that is genuinely available to the institution rather than to the vendor's professional services team. Risk factors, thresholds, list sources, scoring logic and decision paths can be altered without a code release, which changes the economics of tuning. In most incumbent estates a threshold change is a change request, a quote, a test cycle and a quarter. Where a firm can model the change, see the population impact, record the rationale and promote it under its own change control, tuning stops being an annual event and becomes a control. The caveat is that this shifts work rather than removing it, and a buyer without the internal capability to exercise configurability will reproduce the vendor dependency it was trying to escape.

The third strength is speed of deployment relative to the incumbents, which is not trivial when the alternative is a multi-year replacement programme with a high abandonment rate. A mid-sized institution with a defined scope, clean customer data and a willingness to accept the platform's opinions can reach production considerably faster than received wisdom suggests. That matters most to firms under a remediation commitment with a dated deliverable.

Where the Limitations Are

The first limitation is the install base at tier one scale, and it is a factual question rather than a slight. The category's challengers have strong references among mid-market banks, payment institutions, electronic money firms and asset managers, and thinner references among global systemically important banks running multiple booking centres, dozens of legacy source systems and payment volumes in the hundreds of millions. That is not evidence the platform fails at that scale. It is evidence that a tier one buyer would be the one proving it, and such a buyer should price the risk, demand named references at comparable volume, and be sceptical of an architecture diagram offered in place of an operating reference.

The second limitation follows directly and concerns throughput and latency in the real time payment path. Batch and onboarding screening is a forgiving workload. Real time payment screening is not: it has a hard latency budget measured in tens of milliseconds, a peak profile driven by settlement cycles rather than averages, and a failure mode that stops the rail rather than lengthening a queue. Entity resolution at request time is computationally heavier than string matching, which is precisely why it produces better answers, and what the resolution layer does to the latency distribution at the ninety-ninth percentile under peak load is the single most important technical question in this evaluation, and the hardest to answer from a demonstration environment.

The third limitation is functional coverage beyond screening. Transaction monitoring scores 3 and enterprise fraud risk management scores 2 for a reason: this is a screening and customer risk platform, not a monitoring or fraud platform, and it should not be bought as a consolidation play. Buyers under pressure to reduce vendor count talk themselves into believing a strong decisioning engine in one domain will extend into adjacent ones, and the extension is always longer and less complete than the roadmap implies. Client lifecycle orchestration at 4 carries the same warning: the platform will make decisions, but the case management, document collection, approval workflow and periodic review orchestration around those decisions remain somebody else's problem.

The fourth limitation is structural and applies to the whole category. A platform whose principal advantage is data breadth depends on data it licenses from others, and the commercial terms of those licences sit upstream of the buyer's contract. Establish which sources are proprietary, which are licensed, what happens to coverage if a licence is not renewed, whether derived data may be retained on termination, and whether any underlying provider restricts what the buyer may do with the output. Alongside that sits the model governance burden, which the buyer carries whatever the vendor says: development evidence, validation by a party independent of the vendor, explainability sufficient to justify a specific decision about a specific customer, ongoing performance monitoring and a defensible position on bias. The EBA outsourcing guidelines and DORA apply in the ordinary way, and a younger vendor carries a smaller assurance apparatus, so diligence will take longer than the sponsor assumes.

Questions to Press in the Demo

Steer the session away from the resolution demonstration, which is the product's best moment and proves the least, and towards the three things that decide the outcome: behaviour at your volumes, what you can evidence to a supervisor, and what happens to the data underneath.

• Run our own twelve month historical payment file, at our real peak volume, in an environment we specify, and show us the full latency distribution including the ninety-ninth percentile and the behaviour under a deliberately injected list refresh during peak.

• Name three production clients at our transaction volume and organisational complexity, tell us when each went live, and let us speak to the operations lead rather than the sponsor.

• Take a single alert disposition from that run and produce the complete explanation a supervisor would require: which sources contributed, how the entity was resolved, which model or rule drove the score, what would have had to differ to change the outcome, and how we reproduce that same explanation two years from now.

• Set out every underlying data source you license rather than own, the renewal exposure on each, what our coverage looks like if a major source lapses, and precisely what derived data we may retain on termination.

• Show us your model documentation and validation pack as it would be handed to our independent model validation function, and tell us which parts of it you will not release and why.

Verdict

Buy Sigma360 if you are replacing a legacy list matching engine and your problem is genuinely one of data quality, entity resolution and false positive volume rather than throughput at extreme scale. Mid-sized banks, payment institutions, electronic money firms and firms operating under a dated remediation commitment are the natural buyers, and for them 6.5 is, if anything, conservative. Buy it with an internal owner for configuration, a model validation plan that does not depend on the vendor, and a data licensing schedule read by someone who understands upstream terms.

Do not buy it as an enterprise financial crime suite, do not expect transaction monitoring or fraud coverage to arrive on the roadmap timetable, and do not buy it for the real time payment path at tier one volumes without having proved the latency distribution on your own data first. It pairs with a transaction monitoring platform, a case management system owning the audit trail and the licence and exemption record, a fraud stack, and an orchestration layer for client lifecycle. Bought inside those boundaries it is a strong modernisation of a genuinely dated control. Bought outside them it becomes an expensive partial replacement running alongside the estate it was meant to retire.

Suggested Next Steps

• Define before any demonstration whether your problem is resolution quality or throughput, and size the evaluation accordingly, because the platform answers the first convincingly and the second only on evidence you must generate yourself.

• Run a like-for-like comparison against the incumbent on your own frozen historical data, measuring alert volume at equivalent recall and precision at your actual daily review capacity rather than at a threshold chosen by the vendor.

• Commission an independent model validation plan at evaluation stage, and make the release of development and validation documentation a contractual condition rather than a matter of vendor goodwill.

• Obtain the full underlying data licensing position, including renewal exposure, coverage impact on lapse and post-termination retention rights for derived data, and complete EBA outsourcing and DORA diligence early, covering subcontracting, data locations, concentration and an executable exit plan.

Sources: Office of Financial Sanctions Implementation, Office of Foreign Assets Control, HM Treasury, EU Council and European Commission, Financial Conduct Authority, Prudential Regulation Authority, European Banking Authority, DORA, AMLA, FATF, Wolfsberg Group, Information Commissioner's Office, TrustSphere Risk Index, April 2026.

TrustSphere helps financial institutions design and deploy intelligent fraud and financial crime detection solutions. Visit www.trustsphere.ai