First steps

If you are reading this, you have already joined Koywe and are using the platform. Welcome!

This guide walks you, in order, through what is left to get your account ready to operate: who is who on your team, how each operation is signed, and which approval policy rules to write before your first one.

Logging in for the first time

If you were able to log in and access our portal, it is because these things already happened behind the scenes:

We verified your company’s details
The details you entered during onboarding were reviewed and approved.
Your organization was created
It is the top level of your account: it holds your companies, your users, and your approval policy rules.
Your first company (or merchant) was created
It is where your transactions and operations are recorded.
Your accounts were opened
The accounts and balances you will operate with, inside that company.
The first user was assigned a role
Whoever started the onboarding request gets the Super Admin role and becomes the organization’s root user. If you joined later by invitation, you have the role a Super Admin user or an Admin user assigned to you.
An approval policy rule was created (security measure)
We applied a rule that blocks every type of operation until the rules you want are defined.

There is only one more important thing left to do:

Create your passkey
It is the first thing you must do. Once it is set up, you can start making your first operations.
Note: a passkey is your signature inside Koywe — your device’s fingerprint, Face ID, or PIN. It replaces the password and confirms each operation. If you want the details, it is all in Passkeys.

What you should know about user roles

Our ecosystem has different user profiles, or roles. Each one comes with a set of permissions that defines which actions it can perform and which views it can access — what is not allowed does not show up. There are five:

1
Super AdminFull
Full access. Can operate, approve, and change the approval policy rules.
2
AdminGovernance
Manages users, companies, and the approval policy rules. Does not initiate or sign payments.
3
Treasury ManagerFinancial
Initiates, signs, and approves money movements. Does not change the approval policy rules.
4
OperatorOperational
Runs the day to day: initiates payments and manages contacts. Does not sign or approve.
5
ViewerRead-only
Read-only. Sees transactions, balances, and reports, but does not change anything.

Note: they are sorted from widest to narrowest scope.

The user who registers the organization with Koywe, who gets the Super Admin role and creates their passkey as the first step, is what we call the root user.

This user manages the security of every operation in your accounts

Their passkey is what enables the organization to operate: without it, nobody else can register theirs.

This is what they can do:

Approves or rejects the creation of each passkey
When someone on the team creates theirs, it stays pending until the root user authorizes it. It expires in 24 hours.
Helps recover a lost passkey
If someone loses their device, the root user starts the recovery and that person gets an email code to create a new one.
Approves invitations with sensitive permissions
Inviting someone as an Operator, Treasury Manager, Admin, or Super Admin user waits for their authorization before it is sent.
Creates and deletes approval policy rules
Because of their Super Admin role, they define what is allowed, what needs approval, and what is denied.
Approves access to the organization wallet
It is the crypto wallet Koywe creates along with the root user’s passkey, where your stablecoins live and where crypto operations are signed from. Anyone who needs to sign there goes through their authorization.

Looks after their own device

They can recover anyone’s passkey, but if they lose their own they must contact Koywe’s support team to handle the recovery.

Note: we recommend that this seat goes to a trusted person with formal responsibility in the company —a legal representative, a partner, or the head of finance—. The rest of the team’s ability to operate depends on their passkey.

To recap:

Root user (Super Admin)

A status you get at onboarding

Only one per organization, and it cannot be reassigned
It is the user who registers the organization, and the first thing they do is create their passkey
Decides who can sign and who can access what

Role (Super Admin, Admin, Treasury Manager, and two more)

A permission that is granted

Several per person, and they can be changed whenever needed
A Super Admin user or an Admin user assigns it to you when they invite you, and the permissions add up

Want to know more about what each role can do? See each role’s page.

What you should know when starting an operation

Every operation goes through three checks, in this order: your role lets you attempt it, the approval policy decides whether it goes ahead, and your passkey confirms it. If any of the three fails, the operation does not go out.

Prerequisites

1 · Roles that can initiate operations

Only the Operator, Treasury Manager, and Super Admin roles can initiate an operation.

The other two roles are left out
The Admin user manages users, companies, and rules, but cannot initiate operations. And the Viewer user can only look.

Want to know more about this? See each role’s page.

2 · Required approval policy

At least one approval policy rule must exist. Each rule defines whether the operation goes out with your signature or waits for someone else’s approval.

Who can define them
A Super Admin user — or an Admin user, if a Super Admin user enabled that rule for them first.
Without an approval policy, nothing can be operated
It does not leave everything open: it is the opposite. If your organization has no written rules, every operation is denied, even a Super Admin user’s.

Note: if you are not yet sure which controls you want, add at least one rule that allows everything and adjust it later. It is better than being left with a blocked account.

Want to know more about this? See the Approval policy page.

3 · Using passkeys

Each person needs their passkey created and approved by the root user. It is what confirms each operation: without it, the operation waits for your signature and does not move forward.

Want to know more about this? See the Passkeys page.

To sum up

If you are the root user

You already have a passkey, but no extra privileges

You create the operation from your company
The approval policy evaluates you like anyone else
You sign with your passkey and it runs
Being root does not exempt you from the approval policy or let you approve your own operations

If you are a user with a role

You need your passkey approved first

You create the operation, if your role allows it
The approval policy evaluates it
You sign with your passkey
If the rule requires approval, it waits until someone else signs

Pending is not an error

When a rule requires approval, both sides sign: first the initiator, then the approver. The operation completes on its own once both signatures are in.

Next steps

User roles — what each one can do and why two people see different screens. Start with Access by role.
Passkeys — the organization’s first one, each person’s, and the two ways to sign.
Approval policy — how the rule list works and why without written rules you cannot operate.
Troubleshooting — the most common symptoms, what they really mean, and how to get unstuck.

If you are looking for the technical details: Transactional Policy and Passkeys and Approvals.