What a transparent AML engine changes: the Marble approach

Ask a compliance team what their fraud and AML setup costs them, and the answer is rarely "the fraud we missed." It is the alerts. The queue of flagged transactions that turn out to be nothing, reviewed one by one, day after day. Across the industry, the large majority of AML alerts are false positives, and every one of them takes an analyst's time to clear.

So detection, on its own, is not the whole story. Catching more is easy if you are willing to flag everything. The harder question is what happens over time: as fraud patterns shift, as a new typology appears, as the false-positive rate creeps up, how quickly can the people running the transaction monitoring system understand what it is doing and change it? That is where different tools take genuinely different paths, and it is worth understanding why.

Two ends of a spectrum

Fraud and AML tooling sits on a spectrum, and both ends are legitimate answers to real constraints.

At one end are proprietary, model-driven engines. They arrive tuned, they score a transaction out of the box, and they ask you to trust the score. That trade once looked clean: less to configure, less to maintain, a vendor carrying the model. But the ground is shifting under it. Regulators increasingly expect a firm to show how its detection reaches a decision, not just report that it ran, and a score you cannot open is getting harder to stand behind on that basis. The more the rulebook leans on explainability, the more a black box turns from a convenience into a compliance liability. It is a point worth holding onto, because it comes back later in this piece.

At the other end are transparent, configurable engines. Instead of a score to trust, they give you the logic itself: the rules, the data, the reasons an alert fired. That asks more of the team that runs it, and in return, it hands them control over how detection works and how it evolves. For a team that wants to own its detection program, that control is the point.

Neither end is the right answer in the abstract. They optimise for different things. Marble sits firmly at the transparent end, and built its whole product around what that end makes possible. That is what this piece is about.

What an open engine actually changes day to day

It is a real-time decision engine for fraud and AML, and its core is open source. In practice, three things follow from that, and they are the reasons a team chooses this approach on purpose.

• The first is that you can see why. When a Marble rule fires, the reason is legible: this transaction crossed this threshold under this scenario, on this data. There is no interpretation gap between the alert and the explanation, because the rule is the explanation. Marble's own users put it plainly: with a transparent engine, you know why an alert is raised, rather than inferring it after the fact.

• The second is that you can change it, fast. Fraud does not wait for a vendor's release cycle. When a new pattern appears on a Monday, a team running an open rule engine can write or adjust a scenario and have it live in hours, not wait for a retrain or a roadmap slot. Marble's AI no-code rule builder is designed for exactly this: compliance and risk people, not just engineers, building and updating detection scenarios directly, drawing on a shared rule library rather than starting from a blank page.

• The third is that you can bring the false-positive rate down yourself. When you can read a rule, you can troubleshoot it. A queue drowning in noise is a rule that needs tuning, and with an open engine that tuning is in your hands, informed by analytics on hit rates and false-positive rates per customer type, payment method, or any dimension in your own data. You are not filing a ticket and hoping; you are adjusting the thing directly.

An engine is only as good as the data it sees

Detection quality is not only about the rules. It is about what the rules can see. A monitoring tool wired to a partial slice of your data will miss whatever plays out in the part it cannot reach. And the same blind spot follows the case downstream: an analyst investigating an alert can only reason about the data in front of them. More data does not just catch more, it explains more. It sharpens both the detection at the front and the investigation behind it, where the reviewer needs the full picture to clear a case or escalate it with confidence.

Marble is built around a fully open data model that mirrors your own data warehouse and connects to whatever the decision depends on: transaction databases, KYC providers, third-party data sources, core banking. Because the model mirrors your warehouse rather than a vendor's fixed template, the payoff starts before the first rule is even written. An open engine slots into the systems you already run instead of demanding a migration around it. So integration is lighter and the path to going live is shorter. Marble's connectors and API are built for that: get the data flowing, map it once, and a compliance team is tuning real scenarios in weeks, not staring at a year-long implementation. It handles any payment scheme, including the unusual ones, because the data model bends to your reality rather than the other way round.

That breadth is what makes real-time meaningful. Assessing a transaction the moment it happens, against the full picture rather than a subset, is a different exercise from scoring it after the fact on partial data. Both have their place, but only the first can introduce friction or block an operation while it still matters. This is also why an open engine pairs naturally with multi-supplier orchestration: the detection sees everything, and the action layer coordinates every provider around it.

In regulated work, explainability is not optional

There is a reason the transparent end of the spectrum matters especially in regulated finance, beyond operational convenience.

A regulator asking why a given alert fired, or why a given transaction was cleared, is not satisfied by "the model decided." Under DORA and the incoming AMLR rulebook, a firm is expected to demonstrate how its detection works, not just that it runs. An engine whose logic is legible, versioned, and auditable without time limits answers that expectation directly. Marble keeps every rule change and every case action in a searchable, unalterable audit trail, and its open-source core means the detection logic can be deployed on-premise or self-hosted, with the firm's data staying under its own control and, where it matters, never leaving its infrastructure. It is the same property teams running crypto operations lean on hardest, where transaction typologies shift fastest and the burden of proof is highest.

Explainability, in other words, is the same property serving two masters: the analyst who needs to trust and tune the system, and the regulator who needs to be shown how it works. A transparent engine gives both the same answer.

From an explained alert to a governed outcome

Get this right, a decision engine you can see into, adjust, feed with all your data, and account for, and you have a detection program you actually own rather than rent. Marble built its product on exactly that premise.

But an alert, however well explained, is still an input. Something has to take it from there: route it to the right reviewer, escalate it when it needs a second set of eyes, hold or restrict the operation while the case is open, and record who did what, when, and why, so the whole sequence holds up later. Here Marble gives compliance teams a choice rather than a constraint. Marble runs that full lifecycle in its own AI-powered case manager, where alerts, decisions, context, and the audit trail sit in one place, and its no-code workflows route, assign, and escalate cases automatically. Those automations are built to support the analyst, not sideline them: every alert arrives pre-analyzed, the busywork of gathering context is done up front, and the reviewer's judgment lands on a case that is already assembled. A team that wants one platform end to end can run detection, investigation, and reporting inside Marble, with no gaps or cracks between them.

The same openness means a team that has already built its operational stack does not have to replace it. Marble can be the detection brick alone, feeding clean, explained decisions into whatever runs downstream. That flexibility is the point: Marble adapts to the shape of your program, whether that program lives entirely inside Marble or spans several systems you already trust.

That operational layer, where an alert becomes a governed set of actions on top of a single audit trail, is where Forest sits. Where a firm coordinates many providers across a wider operation, Marble's decisions flow into Forest workflows that a compliance team and its AI agents run under the same roles and permissions, with AI governance applied identically to humans and agents. The two teams are working together: Marble producing decisions a team can explain, Forest running the governed operation those decisions set in motion.

Marble tells you why an alert exists, and can carry that decision through to a governed, recorded outcome. Where the operation reaches beyond it, Forest extends the same discipline across the wider stack. In fraud and AML, detection was never the end of the job, and with a transparent engine underneath it, neither the analyst nor the regulator is ever left guessing.

Get Marble and Forest running on your alert queue

If your fraud and AML detection runs on a black-box score and you need rules your compliance team can read, change and defend, talk to Marble.

If your team already has a transparent detection engine and still stitches the operation around it by hand every time a case needs to move, book a Forest demo and show us the flow you're trying to run.

Forest is the operational infrastructure for regulated fintechs. Compliance, ops, and support teams work on your systems alongside your AI agents, under one permission model and one audit trail. On your own infrastructure. Learn more at forest.app.