Business · Approvals

Some decisions
should need two people.

Controls that depend on everyone behaving are not controls. BINK enforces four eyes in the code: the person who raised a request can never approve it, only the roles a policy names may vote, one rejection ends it, and every decision is written to a record the business owns.

Talk to us See roles and access

What a policy decides

WhenAlways, or only above an amount you set

WhoThe roles allowed to vote on it

How manyThe number of approvals required

CurrencyThe currency the threshold is measured in

EnabledSwitched on or off without deleting it

One policy per kind of decision, per business — so there is never a question about which rule applied.

ApprovalsUp to ten, independently

RejectionOne is enough to stop it

Self-approvalRefused, and reported

RecordImmutable, and exportable

Enforced

What it will not let happen.

An approval system is defined by what it refuses. Two of these do more than refuse — they raise a critical incident, because an attempted bypass is worth knowing about.

AttemptWhat is triedWhat happens

Self-approvalThe requester votes on their own requestRefused, and raised as a critical incident

Role not listedA member whose role is not on the policy votesRefused, and raised as a critical incident

Inactive memberA suspended or removed member votesRefused

Double voteThe same approver votes twiceOne vote per approver; the later one replaces it

Any rejectionOne approver rejectsThe request ends immediately, regardless of approvals

No decisionThe window passes without resolutionThe request expires on its own

The lifecycle

Raised to resolved.

RaisedAgainst a policyA request is created when the policy says one is needed.
RoutedTo eligible rolesOnly the roles named on the policy may vote.
VotedIndependentlyOne vote each, changeable until it finalises.
ResolvedOr expiredApproved, rejected, cancelled — or timed out.

What you get

Controls that hold.

Each of these exists because of a specific way approvals fail in practice — one person acting alone, a rubber stamp, or a queue that quietly ages into consent.

Never your own request

The requester cannot approve what they raised. The attempt is not merely blocked — it is recorded as a critical incident, because someone trying is information in itself.

As many as it takes

A policy can require up to ten independent approvals. Consensus is counted, not assumed from the first person to click.

One rejection ends it

A single rejection stops the request immediately, whatever the approval count. Objection outweighs agreement, which is the correct default for money.

Thresholds you set

A policy can require approval on everything, or only above an amount in a currency you nominate. Routine work is not made to queue behind a control designed for exceptions.

Requests expire

A request that nobody resolves times out rather than sitting pending indefinitely, so a stale queue cannot quietly become an approved one.

A record you own

Policy changes, requests, every vote and every cancellation are written to an immutable company audit log with actor, role and address — readable and exportable without asking BINK.

Scope, stated

What routes through it.

The engine and its guarantees are one thing; what currently hands work to it is another, and the difference is worth being exact about.

Expense claims are what routes through the approval engine today. Policies for payouts, refunds, settlement and treasury actions can be configured, but those paths do not yet raise approval requests — so BINK does not claim they are held automatically.

What routes in today: Expense claims are what currently flows through the engine. Approval on payouts, refunds, settlement and treasury actions is configurable, but those paths do not yet hand work to it.
Where no policy exists: If no policy is configured for something, it proceeds without approval. Approval is opt-in by policy rather than on by default, and knowing that matters more than assuming otherwise.
One round: Voting is a single flat round. There are no sequential stages, escalation tiers or routing that changes with the amount band or department.
Changing a vote: An approver can revise their decision until the request finalises, so a vote cast before a question was answered is not permanent.
Who can cancel: The requester or the owner, and the cancellation is written to the audit log like any other decision.
Where you approve: Approvals happen in BINK. There is no email, mobile or chat approval surface today.

In the platform