Set Your Rules Once, Automate Every Fund Disbursement

ANATOMY OF A RULE

If this, then that

A rule is a single piece of logic: when a condition is met, an action fires. Define it once, and Hudson runs it on every account and transaction. Chain rules together and the same engine handles conditions of any complexity, one rule's outcome feeding the next.

Written in plain logic

Conditions and actions read like a checklist, not code.

Versioned forever

Every edit creates a new version. Old runs reference the rule version that fired them.

Chain into complex logic

String simple rules into multi-step chains, where one rule's result feeds the next.

FROM CONDITION TO ACTION

A rule chain, evaluated step-by-step

Rules are tied to three kinds of conditions: time-based (e.g., 30d clock expired), activity-based (e.g., a payment landing), or document-based (e.g., waiver uploaded). Chain them together and Hudson evaluates each rule execution, in order, to get to the correct outcome.

WHY IT MATTERS

Let the busywork run itself

Every rule that fires is a task an analyst didn't have to touch. Hudson absorbs the manual work that fills a banker's day so your team's hours  go where they actually move the business: onboarding the next client, structuring the next deal, deepening the relationships already on  the books.

Capacity scales with deposits, not headcount.

Why Hudson?

A single rules engine that turns all your procedures into actions and keeps your team out of the busywork.

Automate every trigger, disbursement, approval, and deadline

Build and edit rules in plain logic, with no code and no vendor tickets

Chain simple rules into the most complex release logic

Version everything, so past actions remain explainable

Frequently asked questions

Do we need engineers to build rules in Hudson?

No. Rules are written in plain logic your operations team can read and edit, with no code and no dependency on outside vendors.

Can rules handle complex, multi-step conditions?

Yes. Simple rules chain into evaluation sequences, so a release that depends on several conditions runs as a single evaluation chain.

What kinds of conditions can trigger a rule?

Rules can be triggered by time-based conditions (a date or deadline), activity-based conditions (a payment or balance event), or documentation-based conditions (a verified document upload).

What happens if we change a rule while transactions are in progress?

Every edit creates a new version. Live transactions keep running on the version that applied when they started, and the change is fully logged.

Do we start from templates or build rules entirely from scratch?

Hudson ships with pre-built rules and chains for common specialty-deposit activities. They're all editable, and most teams can start working with rules after initial onboarding and training.

How does the rules engine keep past decisions explainable?

Every rule version is preserved, so any past action can be traced back to the exact rule logic that fired it at the time, supporting audit and examiner review.

Can simple rules be chained into more complex disbursement logic?

Yes. Individual rules can be strung together into multi-step chains, where one rule's outcome feeds directly into the next.

Rules Engine