Verkflo is in early access. Book a demo

Compliance automation your auditors can follow

Every run follows a published version, pauses where your procedure needs a person, and leaves a hash-chained record.

Your CEL rules set each run's path, named reviewers make the calls your procedure leaves to people, and the audit log records both.

How Verkflo works

How can we help?

See how we handle your details in our Privacy Policy.

What an auditor can check

  • Versioned specs

    A run is tied to the published version it used, so you can read the procedure as it stood that day.

  • Review pauses

    Runs stop where your procedure reserves a decision for a person, then resume on the answer.

  • Hash-chained audit log

    Runs, reviews and version changes go into one log that you can verify yourself.

How a run stays inside your procedure

Your team writes the branch rules, tests each version, chooses when it goes live and names who reviews.

Rules pick the branch.
Each branch is a CEL condition your team writes and can read.
Steps you can read.
Each step and tool call is recorded against the run.
Test before live.
Scenarios run in the sandbox before a version is published.
Branch rule · KYC ReviewSample data
Company
Corvid Freight
Risk
Medium
Screening hits
1

risk_rating == "High"false || screening.hits > 0true= true

Ask a reviewerApprove

Controls

Controls your auditors will ask about

Runs3.2k
Sent to review6.1%
Oldest waiting2h

Sample data

Target This month Last month JanFebMarAprMay
Above targetReview rate up

Review monitoring Track runs, review rate and wait times for each procedure.

Audit logging

Every action is written to a hash-chained log you can verify.

Capturing.

  • Tom approved Corvid Freight
  • Maya published KYC Review v1.3
  • Priya rotated the Sumsub key
  • Lena exported the audit log

Versioned specs

Each run records the exact version it followed; old versions stay readable.

  • Admin

    • Sumsub
    • ComplyAdvantage
    • Google Drive

    Roles and permissions. Admin, Author, Reviewer and Auditor roles, scoped to each workspace.

  • Hash-chained log. Each entry carries the hash of the one before it. Verifying the log recomputes the chain and flags entries that no longer match.

    • risk == "High"
    • hits > 0
    • risk == "Low"

    Rule-based branches. CEL rules you write pick the branch each run takes.

  • Sandbox before live. New versions run on test data first. Going live is a separate step.

    • KYC high risk
    • Sanctions match
    • Expired document

    Evals before publish. A failing scenario blocks publishing until it is fixed.

  • Secrets in a vault. Steps point to a vault path, and the key stays in the vault.

    • Signed delivery
    • Unsigned delivery
    Reject stale or unsigned

    Signed webhook triggers. Unsigned or stale deliveries are rejected before a run starts.

  • By Mayav1.3Sumsub Fetch applicantVia KYC ReviewExecuted

    Step tracing. Trace every step a run takes, with who started it and what it called.

  • Reporting. See runs, outcomes and review times by procedure.

  • Escalation

    Harbor Lane PEP hit. Approve?

    DenyApprove

    Review approvals. Runs pause for a named reviewer, and the decision is logged.

Frequently asked questions

How does Verkflo decide which branch a run takes?

Rules written in CEL choose the branch, so the same input takes the same path. The model reads documents and drafts notes for the run.

When does a run pause for a person?

Where your procedure says a person decides. The run stops at that step, asks a named reviewer, and carries on from the decision, which is logged.

What does the audit log record, and how is it verified?

Every action in a run is written to the log, and each entry carries the hash of the one before it. You can verify the chain at any time, and an entry that was changed is flagged.

How are API keys and secrets handled?

Secrets live in a vault. Each step holds a reference to the vault path, so the key itself is never pasted into a step.

Can we test a version before it goes live?

Yes. New versions run on test data in the sandbox first, and evals check your scenarios. A failing scenario blocks publishing until it is fixed. Going live is a separate step.

Who can change a procedure?

Access is by role: Admin, Author, Reviewer and Auditor, scoped to each workspace.

How are inbound webhooks secured?

A webhook trigger checks the signature and freshness of each delivery. Unsigned or stale deliveries are rejected before a run starts.

Do you hold security certifications?

Not yet. Ask us about our current security practices during a demo.

Build your first
agent workflow

Show us a procedure with controls you need to evidence, and we'll run it with each step logged.

Book a demo