How it works

It catches the one others wave through.

RiskForge judges a transaction by how it behaves, not just by how big it is, and it can act before the money moves. Here is the kind of thing it catches, and what happens when it does.

Behaviour decides, not the amount.

riskforge / real-timeEVENTdoc 1900418vendor 10023348,200 €RULESthree-way matchbehaviour baselinesegregation of dutiesVERDICTHOLDfour-eyes release0.2 s · confidence 0.97, above the hold band

Most tools watch for big numbers. Errors and inconsistencies rarely announce themselves that way. RiskForge looks at the whole picture, the way an experienced auditor would: who is acting, what they are doing, and whether it fits this person's and this process's usual pattern of activity.

An €812,000 payment run at the usual Tuesday slot, to vendors you always pay, barely registers. A €4,200 run at 18:42 to two vendors nobody has ever seen before lights up immediately. Same system, opposite verdicts, and the small one is the dangerous one. That is the difference between watching amounts and understanding behaviour, and it all happens in real time, before the transaction posts.

Want to see this on your own data? We walk through it live in the demo →

What happens after a hold.

A held transaction is parked, not rejected. The full payload is captured and nothing posts. The responsible control owner sees it in their bucket with the reasons: which baseline broke, the confidence band, the history of similar events. They have two buttons:

  • Release. RiskForge re-posts the transaction automatically from the captured payload. The manager's click is the initiating action and the employee re-keys nothing. Segregation of duties is enforced: the releaser can never be the initiator.
  • Reject. The payload is discarded, nothing ever posts, and the reason is recorded as audit evidence.

Held items age with escalation. An unattended item bumps to a deputy after a configurable time, so a manager in a meeting never blocks operations. And because only the suspicious lines of a batch are held, the rest of a payment run posts normally.

Why this catches what other tools structurally miss.

Most financial errors and irregularities happen inside legitimate access: the right person, the right authorisation, the wrong behaviour. Role-based tools cannot see it, because the access was valid. Log-based tools see a login, not a ledger. RiskForge baselines behaviour inside legitimate access, which is precisely the territory that access analysis, SIEM and process mining leave uncovered.

Own your controls.

See RiskForge on your own processes.

In the demo we walk through what is already built and running on SAP and the connected live systems, and what we can set up for your business. No slides, just the product and a plan.

Request a demo