Business · Team

Company money.
Precisely bounded access.

More than one person needs to use the business’s funds, and they should not all be able to do the same things. BINK gives a team thirty-two named permissions across seven roles you can extend — tuned per person, revocable, and recorded in a log the business owns.

Talk to us See approvals

The built-in roles

OwnerThe account the business belongs to

AdminRuns the business day to day

FinanceMoney, settlement and reporting

SupportCustomer-facing, not money-moving

DeveloperKeys, webhooks and integration

AnalystReads, and does not change

Read-onlySees the business, touches nothing

A starting point, not a ceiling — a business can define its own roles, and tune any person against the role they hold.

RolesSeven, plus your own

PermissionsThirty-two, individually named

TuningGrant or revoke per person

RecordImmutable, and exportable

What can be governed

Ten domains, thirty-two permissions.

Permissions are named for what they let someone do, in the domain they do it in. Reading payouts and creating them are separate answers, because in a real finance team they are.

DomainActions availableTypically held by

PaymentsRead, create and refundFinance and above

PayoutsRead and request outbound paymentsFinance and above

SettlementsRead and manage settlementFinance and above

InvoicesRead and manage invoicingFinance and above

ApprovalsRead, vote, and manage policySplit — voting and policy are separate

Team & rolesRead, manage members, invite, define rolesAdmin and above

API & webhooksRead and manage keys and endpointsDeveloper and above

Analytics & auditRead reporting and the audit trailAnalyst and above

SecurityRead and manage security settingsAdmin and above

Commerce & POSRead, manage, sell, and manage devicesScoped separately from finance

“Typically held by” describes the built-in roles. Once a business defines its own roles, the mapping is whatever that business decides it is.

The lifecycle

Invite, assign, tune, revoke.

InviteBy emailA hashed, expiring invitation — not a shared password.
AssignA roleOne of seven, or a role your business defines.
TunePer personGrant an extra permission, or revoke one from the role.
RevokeWhen it endsSuspend or remove, with the change recorded.

What you get

Access you can defend.

The test of an access model is not the day you set it up — it is the day somebody asks who could have done this, and when that changed.

Permissions, not tiers

Access is thirty-two individually named permissions across payments, payouts, settlement, invoicing, approvals, keys, analytics, audit, security and commerce — not three tiers with a support ticket for the exceptions.

Roles you can define

The seven built-in roles are a starting point. A company role carries its own permission set, so access can match how the business is actually organised.

Tuned to the person

A member can be granted a permission their role does not carry, or have one revoked from it. The exception is part of the record rather than a second account created to work around the rule.

Invitations that expire

Joining is by an emailed invitation whose token is stored hashed and expires on its own. Nothing is shared, and an unaccepted invitation does not stay live indefinitely.

Ownership can move

The business can be handed to another member deliberately, as a recorded action — so a company is never stranded behind one person’s login.

An immutable record

Every role change, suspension, removal and policy edit writes to a company audit log with the actor, their role, their address and the before and after — readable by the business and exportable as CSV.

Scope, stated

What access does and does not do.

Worth being exact, because "team wallets" could be read as separate balances, and because permissions and spending limits are different mechanisms.

Wallets are held at company level, one per currency — there is no per-member or per-team balance. Spend policies can be defined but are not enforced at card authorisation today, so per-person spending limits are not claimed here.

Whose wallets: The wallets are the company’s, one per currency. What a role changes is who may act on them and what they may do — there is no per-member or per-team balance.
How access resolves: A custom role replaces the built-in role’s permissions; anything granted to the person individually is then added, and anything revoked from them is removed.
Suspension: A suspended member keeps their record and their history but loses the ability to act, so access can be stopped without destroying the trail of what they did.
Where scopes apply: Permissions govern the surfaces they are attached to — team and role management, approvals, invoicing, commerce and point of sale, keys and webhooks among them. BINK does not claim that every endpoint in the platform is scope-gated.
Spend rules: Spend policies can be defined and evaluated, but they are not applied at card authorisation today. Per-person spending limits are therefore not something this page claims.
Audit export: The company audit log is readable without administrator involvement and exports as CSV, so a review does not depend on BINK producing it for you.

In the platform