From keystroke to verdict in 0.2 seconds.
RiskForge screens an SAP transaction in five steps, fast enough to act before the transaction commits. Here is the full journey, and what happens after a hold.
The five steps of a real-time decision.
Capture
An employee posts a transaction, say a payment run. The SAP hook signals RiskForge with the transaction's facts while the change-data feed delivers the surrounding context.
Understand
The event is read in full context: who is acting, what they are doing, how much is involved, and what is normal for exactly this person and this process.
Compare
The transaction is compared against that picture of normal and the applicable rule set, fast enough that SAP never waits.
Score
The result is a confidence band, not a yes/no alarm. A €812,000 payment run at the usual Tuesday slot to the standing vendor list scores low. A €4,200 run at 18:42 to two never-seen vendors scores high. Behaviour decides, not the amount.
Decide
Below the threshold, the transaction posts untouched. Above it, enforcement mode holds it before commit while monitoring mode lets it post and queues it for review. Either way the decision is logged to the evidence vault, end to end in under 200 milliseconds.
Want to see this running on real data? We walk through the full flow 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 fraud and error happens 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.
See RiskForge on your own processes.
A 30-minute walkthrough against realistic SAP scenarios: payment runs, journal entries, transports. No slides, just the actual product.