Bancoli Smart Wallets are self-custodial: only the person who can sign in to the wallet identity and approve the action can move funds. That is stronger control than a shared bank ledger—and a real operating constraint for multi-user teams.
This article is for finance leaders, controllers, founders, and operations leads at multi-user corporate accounts. Design signing authority—and the security of the Google account behind it—before the first wallet activation, not after funds arrive.
What a self-custodial wallet is
Your Bancoli Smart Wallet is an on-chain smart wallet. Neither Bancoli nor the wallet technology provider holds the signing key for you. The person who controls the wallet identity must sign in and approve each operation (for example with a passkey or device-local approval).
Layer | What it does | Who controls it |
|---|---|---|
Wallet identity | The Google account chosen at wallet setup (Google sign-in) | Whoever can open that Google account |
Signing (passkey / device) | Authorizes on-chain transfers and spend permissions | Whoever can unlock that wallet session |
Bancoli app / platform | Dashboard, compliance rails, settlement pathways, and feature access | Bancoli — does not replace wallet signing |
Important: If only one person can sign in to the wallet identity, only that person can sign transactions—even if several people have Bancoli business logins.
Activation — the account owner must turn the wallet on
Account readiness is not the same as a live wallet. An authorized owner must complete wallet activation before the team can use self-custodial balances and transfers.
Confirm the corporate Bancoli account is ready — verification must be sufficient for wallet setup on your plan and location.
Owner starts wallet activation — the owner begins the self-custodial wallet flow in Bancoli.
Choose the Google sign-in identity deliberately — this choice is hard to reverse for operations. Prefer a company Google account if more than one person must sign.
Harden that Google account before funding — phishing-resistant 2FA, a registered backup key, and company-owned recovery details.
Complete 2FA and passkey / device setup — every intended signer needs reliable access to the Google account, 2FA, and signing device.
Validate a test action before live volume — intended operators complete a low-value signed action before real payment volume.
Identity and Google account security
Wallets are tied to a Google sign-in account. That account does not have to match your Bancoli business login, but it becomes the gate for wallet access and signing.
Critical product constraint: Operators must sign in as the wallet identity before they can sign a transaction. Bancoli multi-user roles do not automatically grant wallet signing rights.
Anyone who will initiate wallet transfers must authenticate as that Google identity.
They also need the associated 2FA (passkey, security key, or authenticator app).
A personal founder email means only that founder can sign—teammates cannot operate the wallet.
This applies to every multi-user client, not only certain jurisdictions.
Treat that Google account as treasury infrastructure: phishing-resistant 2FA (passkeys or hardware keys), a primary and backup key stored separately, no SMS fallback where possible, company-owned recovery contacts, and Workspace 2-Step Verification enforcement where applicable.
Google Advanced Protection is recommended for wallet identities. Pilot with one signer (confirm wallet open + low-value signed action + recovery path) before enrolling the rest.
Multi-user operating models
Pick one model before activation. Changing later is operationally painful.
Model | How it works | Best when | Watch-outs |
|---|---|---|---|
A. Dedicated wallet ops | One or two named people own SSO, 2FA, and signing | Most companies | Cover for leave; document succession |
B. Shared company Google | Company Google account with a planned shared 2FA model | Several people must initiate without the founder | Credential discipline; wider blast radius |
C. Founder-only personal | Personal email only the owner controls | Solo operators only | Avoid for teams — single point of failure |
Recommendation: Default to Model A on a company Google account, protected with hardware security keys and Advanced Protection. Use Model B only when several people must initiate transfers. Avoid Model C for teams.
What not to do
Do not activate with a personal email if finance must move funds without the owner present.
Do not assume Bancoli user seats equal wallet signers.
Do not rely on SMS codes to protect the wallet’s Google account.
Do not leave 2FA on a single phone or single key with no backup or recovery path.
Do not share personal Google credentials in chat.
Do not enroll every signer in Advanced Protection at once without a pilot.
Do not wait until the first large payout to discover only the owner can sign.
Go-live checklist
Decide Model A or B before the owner starts activation.
If Model B: use a company Google account, not a personal Gmail.
Put a passkey or hardware key on the wallet identity, plus a backup key stored separately.
Use company-owned recovery email and phone; on Workspace, use admin-managed recovery.
Enable Advanced Protection and pilot it with one signer before the rest.
Document who may access the Google identity and who may sign.
Owner activates with the chosen Google sign-in; operators complete a test signed action.
Record succession and brief the team: a Bancoli login is not wallet signing authority.
Key takeaways
Self-custody means your team holds the signing authority. The account owner must activate the wallet. Google sign-in is the gate and can differ from the Bancoli login—so harden that account like treasury infrastructure. Design multi-user access on day one—dedicated ops or a shared company Google, never a personal founder email for team operations.
Availability of wallet features can still depend on your plan, verification status, and location. Your Bancoli dashboard shows what is enabled for your account.