We've now covered two of the three concepts at the core of how Lisk works: Workspaces (the company environment) and Profiles (the people inside it). This post covers the third, and for most finance teams, the one that matters most day to day: Accounts, the place where the money itself actually sits.
What an Account Is
An account is a shared financial account inside a Lisk workspace. It holds a balance, and it's where money moves in and out. Specifically, an account is used to hold a balance, receive funds, send payments, transfer money to another account in the same workspace, withdraw funds to a saved withdrawal method, apply approval rules before money moves, and track its own transaction activity.
It's a financial container, not a person.
Accounts vs. Workspaces
A workspace is the company or team environment. An account lives inside that workspace, and a single workspace can have several accounts, each built for a different business purpose. A typical setup might include:
- Main Account
- Team Budget
- Taxes
- Payroll
- Operations
- Marketing Budget
This is one of the more practical benefits of using Lisk: instead of one undifferentiated balance for the whole business, a workspace can hold its money the way most companies already think about it, split by team, purpose, or use case.
Accounts vs. Profiles
A profile is a person. An account is where money is held. A profile, or member, can be added to an account with a specific role, but the profile itself is never the account.
The Main Account
Every workspace gets a Main Account automatically at setup. It's the default incoming account for all deposits, shown at the top of the accounts list, and marked with a "Default" label. Unlike other accounts, it can't be assigned to a department. In practice, the Main Account functions as the workspace's default operating balance, the place money lands unless a more specific account has been configured to receive it.
What an Account Balance Actually Is
Accounts show balances in dollars. Under the hood, payment account balances are backed by Lisk's USDL stablecoin, but that infrastructure is fully abstracted away. Users see a dollar balance and interact with a dollar account, not a token.
In practice: fiat deposits and supported stablecoin deposits both settle into the Main Account, and outgoing payments convert from the account balance into whichever payout method or rail is selected at send time.
Creating an Account
Account creation is only available to workspace Admins and the Owner, not to regular Members. To create one, an admin or owner goes to the Accounts page, clicks Add account, enters a name, optionally chooses an icon or emoji, a color, and a department, adds workspace members, assigns each of them a role, sets the number of required approvals, and creates the account. It then appears in the workspace's Accounts list.
If someone on your team doesn't see the "Add account" button, it means they don't have permission to create accounts.
Account Identity and Departments
Each account can carry a name, an icon or emoji, a color, and an optional department, such as Finance, Marketing, Operations, or Legal. Departments exist to organize accounts by team or business unit, which makes the product map more naturally to how a business actually organizes its money, rather than forcing everything into one flat list.
Roles on an Account
Beyond the general Owner, Admin, and Member roles at the workspace level (covered in our Profiles post), each account has its own, separate layer of access:
- Approver can act on the account according to that account's approval policy, which can include initiating and approving transactions. Approvers sign their approvals in the Lisk mobile app.
- Viewer has read-only access: they can see the relevant account and transaction information but can't take any financial action. This is useful for people who need visibility without payment authority, like finance reviewers, auditors, department leads, or an HR team member who needs to see a payroll-related account without being able to move money out of it.
These account-level roles are entirely separate from workspace roles. A person can be an approver on one account, a viewer on another, and have no access at all to a third:
| Layer | Role examples | What it controls |
|---|---|---|
| Workspace role | Owner, Admin, Member | General workspace authority |
| Account role | Approver, Viewer | Access and actions on a specific account |
So a real-world example might look like this: a person is a workspace Member, an Approver on the Payroll account, and a Viewer on the Taxes account. All three of those are true at once, and none of them imply the others.
Who Can See What
Account visibility follows the same permission-based logic. Admins see all accounts in the workspace, while members see only the accounts they've been assigned to, and balance totals shown to any given user are scoped to only the accounts and resources they can actually see. That matters most for sensitive accounts, payroll, taxes, legal, or executive expenses being the obvious examples, where a business genuinely doesn't want every team member seeing the full picture.
Approval Policies: The Real Control Layer
Every account has an approval policy, which defines who the approvers are and how many approvals are required before a transaction goes through. Every account must have at least one approver, an account can have up to five approvers, and the approval threshold can never be higher than the number of approvers on the account. Only users with signing capability can be added as approvers in the first place, and if the person initiating a transaction happens to be one of the approvers, their initiation counts as their approval. Any pending approval request that doesn't get resolved expires after 72 hours.
A concrete example: if an account has three approvers and requires two approvals, any transaction from that account needs two of those three people to sign off before it executes.
How Approvals Actually Happen
Account transactions are approved through the Lisk mobile app, not the web app.
The flow works like this: a transaction is started on the web, which shows a waiting-for-approval screen, the approver opens the request on their mobile device, reviews the transaction details, and chooses to approve by confirming with their biometrics or to skip it entirely. Once enough approvals have been collected, the transaction is submitted.
It is important to note that approving and skipping aren't the same thing. Approving counts toward the required threshold. Skipping doesn't count toward it, but it also doesn't block the request, since the transaction can still go through if enough other approvers say yes. If the threshold is never reached, the request simply doesn't take effect and expires after 72 hours.
Getting Money In: Deposits
Accounts receive funds through two supported deposit types. Fiat deposits are handled through Bridge virtual fiat accounts, settle into the Main Account, and are auto-converted into USDL on the backend. Stablecoin deposits currently support USDC on Base only, and follow the same pattern: auto-converted into USDL and settled into the Main Account. Non-stablecoin assets, like ETH, BTC, or LSK, don't go through accounts at all; they're handled through portfolios instead, which we'll cover in a future post.
Virtual fiat accounts themselves are set up at the workspace level and are admin-only. They require Bridge opt-in and business verification, after which Bridge provides real fiat account details for receiving bank transfers, currently supporting USD and EUR. All deposits made through a virtual fiat account land in the Main Account.
One practical note worth flagging: every account also has an onchain address, which exists purely for auditability, so an admin can verify holdings onchain if needed. That address does not convert incoming assets the way the official deposit flow does. In other words, users should always use the deposit flow inside Lisk rather than manually sending funds to an account address, since sending to the wrong address may not produce the expected balance.
Moving Money Between Accounts: Transfers
A transfer moves funds from one account in a workspace to another account in the same workspace, for example, moving money from the Main Account into the Taxes account. To make a transfer, both accounts must belong to the same workspace, the user must be an approver on the source account and at least a viewer on the destination account, the workspace needs at least two accounts to begin with, the source account needs sufficient balance, and the transfer is approved through the mobile app following the source account's own approval policy. Like other pending requests, an unapproved transfer expires after 72 hours.
Getting Money Out: Withdrawals
A withdrawal moves funds out of a workspace account to a saved withdrawal method, either an external bank account or a crypto wallet. Withdrawals start on the web and are approved and signed in the Lisk mobile app, require sufficient account balance, and require the workspace to already have a saved withdrawal method on file. If multiple approvals are needed, each approver signs off in their own mobile app. Pending withdrawal requests also expire after 72 hours.
It's worth distinguishing withdrawals from payments: a withdrawal moves the workspace's own funds to one of its own saved methods, while a payment sends money to someone else entirely.
Sending Payments
Account balances are the source for essentially every outgoing payment type: fiat sends to recipient contacts with bank accounts, crypto sends, bill payments, withdrawals, and internal transfers. The rule that ties it all together is simple: money movement always follows the approval policy of the source account. A payment sent from the Marketing account follows the Marketing account's approval rules.
External sends rely on saved contacts and payout methods, and Lisk's contact-aware send flows check that the destination actually has a valid payment method for the type of send being made, preventing or disabling a selection if it doesn't. That keeps money movement tied to verified recipient data rather than repeated manual entry.
On fees: Lisk charges no commission on transaction types itself. Any partner fees are shown as a single, combined fee line, and network gas fees are absorbed by Lisk rather than passed on or shown to users. If no partner fees apply, the fee line simply shows "Free," and internal transfers between accounts inside the same workspace are always free.
Transaction History and Recordkeeping
Every account shows its activity through a transaction history. Transaction types include deposit, payment, withdrawal, and transfer, and each one moves through a status such as pending, processing, completed, failed, declined, canceled, or refunded. Transactions are visible both on the broader Transactions page and within account-specific views.
Transactions can also carry metadata: categories (workspace-wide labels managed by admins), free-text notes, and attachments like receipts, invoices, contracts, or other supporting documents. That combination is what turns an account from a simple balance tracker into something closer to a real bookkeeping record.
The Security Model, in Summary
Accounts are secured through a combination of account-specific approvers, account-specific approval thresholds, mobile signing with passkeys, expiry on pending approvals, permission-scoped visibility, and admin-controlled configuration. Taken together, this is what makes an account a team finance primitive rather than a single-user wallet.
Even changing those rules is treated as sensitive: adding or removing approvers, or changing the approval threshold, itself requires approval, can only be initiated by an admin, and runs through a similar approval flow as other account actions.
The Bottom Line
Accounts are one of the core primitives of the Lisk product, and they're where operating money actually lives. They connect workspace structure, dollar balances, deposits, payments, withdrawals, internal transfers, members, approvers, viewers, approval policies, mobile signing, transaction history, and the categories, notes, and attachments that turn a balance into a real financial record.
Putting the whole series together: if a workspace is the company environment, and profiles are the people, then accounts are the controlled balances those people use to run their financial operations, with every dollar in and out backed by a clear, auditable approval trail.