NEWPockyt × Circle: native USDC settlement now live →
VisionNews
The connective layer
Money movement
as code, not as
scheduled jobs.
The layer that ties the four primitives together. Define rules — collect here, hold there, convert under these conditions, pay out on this trigger — once, in one place, executed deterministically by the platform. The treasury team writes policy. Pockyt executes.
Why this matters
Money infrastructure has been programmable in theory for decades. In practice, it's been operated by spreadsheets.
The treasury team that wants money to behave a certain way today writes a spreadsheet, builds a dashboard, schedules a job. The platform processes data; the human processes money. Programmable Logic flips that. Money movement becomes deterministic, rule-driven, auditable code — executed by the platform, observed by the human.

Today: treasury as projects.

Every new flow is a project: a scheduled job, a script, a manual reconciliation, an alert on top. When the rules change — new market, new vendor, new compliance constraint — the engineering team rebuilds the plumbing. Treasury policy lives in a wiki; treasury execution lives in a hundred scripts.

With Programmable Logic: treasury as policy.

Rules live in one place, expressed declaratively, version-controlled. New flows are new rules, not new projects. The treasury team owns policy; engineering owns the platform; the platform owns execution. Audit trails are automatic.

How it works
Rules over the same surface as the rest of Pockyt.

Triggers

Rules fire on time-based triggers (schedules, cutoffs), event-based triggers (incoming payment, balance threshold, webhook from your system), or external signals (FX rate condition, holiday calendar, third-party API).

Conditions

Composable predicates over the Pockyt ledger: balances, exposures, transaction history, open holds, sub-account state. Plus access to your own data via webhook lookups, so rules can reference your KYC state, invoice status, or any other operational signal.

Actions

Anything the Pockyt API exposes: sweep, convert, pay out, hold, route, notify. Actions are themselves auditable — every rule execution produces a structured "why" trace.

Capabilities
What lives in the connective layer.

01

Declarative rule definitions

Express policy as code: triggers, conditions, actions. Version-controlled. Reviewable. Diff-able.

02

Composable across primitives

One rule can read balances from Treasury, trigger off a Checkout event, and issue a Payout. The primitives are designed to compose.

03

External signal integration

Rules can reference your own systems via webhook lookups: KYC state, invoice status, fraud signals, business logic.

04

Structured execution traces

Every rule firing produces a "why" trace — which triggers fired, which conditions evaluated, what actions executed.

05

Dry-run mode

Simulate a rule against current ledger state without side effects. See what would happen before deploying it live.

06

Human approval gates

Any rule can require human approval for actions above a threshold. The rule proposes; the human confirms.

When to use
Where rules replace ops.

Scheduled treasury operations

Weekly sweeps, monthly currency conversions, end-of-quarter rebalancing. Anything currently run as a scheduled job becomes a rule, with the same determinism but a fraction of the maintenance.

Marketplace settlement policy

"When seller balance exceeds threshold, on payout day, if no holds, pay out via preferred rail" — the kind of policy that's natural to write and a project to implement. Rules collapse the gap.

Event-driven routing

Incoming Checkout should route differently based on amount, source, or downstream context. Rules express that routing once; the platform executes it on every event.

Treasury as policy.

Talk to our team about expressing your money movement as rules rather than as projects.