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?

No. Rules are written in plain logic your ops team can read and edit. There is no code and no dependency on vendors.

Can rules handle complex, multi-step conditions?

Absolutely. 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?

Time-based (a date or deadline), activity-based (a payment or balance event), and documentation-based (a verified document).

What happens when we change a rule mid-transaction?

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

Do we start from templates or build everything ourselves?

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

Rules Engine