Stablecoin Treasury Permissions: What CFOs, Controllers, Admins, and Clerks Should Be Allowed to Do

A stablecoin treasury usually starts with one person and one login. A founder, a controller, or a single operations hire sets up a wallet, sends a handful of USDC or USDT payments a month, and tracks everything in a spreadsheet. That arrangement works until the team grows. The moment a second person needs to initiate payments, a third needs to see balances without touching funds, and a fourth , usually the CFO , needs assurance that no single employee can move company money alone, “who has the login” stops being an adequate access model. The real question becomes who is allowed to do what, and who checks it.

This matters more with stablecoins than with a traditional bank transfer. A wire can sometimes be recalled within a window; a payment broadcast to a blockchain network generally cannot. Once it settles, it settles. That makes the design of who can initiate, who can approve, and who can administer a stablecoin treasury a governance decision worth making deliberately, not one that happens by default because everyone was handed the same wallet and password.

Where the shared-login model breaks down

Consider a payment service provider that starts by sending 15–20 stablecoin payouts a month to a handful of contractors. One person , the founder or the operations lead , holds the only credentials, initiates every payment, and reconciles it against a spreadsheet at month-end. It's manual, but it's controllable, because one person can hold the entire process in their head.

Growth changes that math quickly. At a few hundred payments a month across dozens of beneficiaries in multiple countries, the same person can no longer initiate every payment personally. A second operator joins, then a third. Finance wants visibility into balances without wanting to be the one clicking send. Compliance wants confirmation that a beneficiary was screened before a payment went out. And the CFO wants a straightforward answer to a straightforward question: if $250,000 moved out of the company's ledger yesterday, who submitted it, and who approved it?

A shared wallet and a shared password can't answer that. There's no record of which team member actually initiated a given transfer, no structural way to stop one person from both requesting and approving the same payment, and no way to limit who can see the company's total treasury position versus who merely needs to send payments against a beneficiary list. The workflow that was fine for one person becomes a genuine control gap for a team.

Segregation of duties is the actual design problem

The principle finance teams reach for here isn't new , it's the same segregation-of-duties logic that governs accounts payable, wire approvals, and payroll: no single person should be able to both initiate and approve the movement of company funds. Applied to a stablecoin treasury, that means the person who submits a payment to a beneficiary should not be the same person who releases it, and the person who can change an approval threshold should not be the only person who also approves against that threshold.

This isn't a hypothetical risk. In its Occupational Fraud 2026: A Report to the Nations, the Association of Certified Fraud Examiners found that more than half of the fraud cases it studied involved either a lack of internal controls or the override of controls that already existed, with a median loss of $104,000 and an average loss exceeding $1.4 million per scheme. Separately, the Association for Financial Professionals' payments fraud research has found that more than three-quarters of US organizations experienced attempted or actual payments fraud in the prior year. Neither figure is specific to stablecoins , both describe payments and disbursement fraud broadly , but the underlying mechanism, a single point of control with no independent check, is exactly what segregation of duties exists to close, and it applies just as directly to a treasury moving USDC as it does to one cutting checks.

For regional banks specifically, this isn't only good practice , it's becoming a supervisory expectation. As US banking regulators build out the rules implementing the GENIUS Act, industry legal analysis of the OCC's 2026 rulemaking notes that banks engaging in stablecoin activity are expected to maintain internal controls that include segregation of duties, formal escalation protocols, and independent testing, overseen by a senior management structure with clearly defined responsibility. A bank building a stablecoin treasury process without that structure isn't just carrying operational risk , it's building something an examiner will eventually ask about.

What AlphaPoint Treasury actually enforces today

Before mapping business roles onto a system, it's worth being precise about what the platform itself does. AlphaPoint Treasury runs on a Role-Based Access Control (RBAC) architecture built around exactly two system-level roles: Treasury Admin and Treasury Clerk. Documented sections of AlphaPoint's own user guide are tagged by access level , Admin Only, Admin & Clerk, or Process Flow, where a Clerk starts the action and an Admin finishes it , across company onboarding, access and security, wallet and liquidity management, and accounts payable. (Accounts Receivable, Treasury Governance, and Reporting & Settings appear in the current guide as placeholder chapters without that tagging yet.) The platform calls the underlying maker-checker pattern its “Four-Eyes” handshake.

A few specific, documented mechanics are worth knowing. Note that the guide uses three separate settings labels, not one interchangeable term , they're kept distinct below:

• Payments: a Clerk can initiate a payment, but if it exceeds the Payments Approval Threshold configured in the Role Settings, it moves to Pending Approval and lands in the Admin's Action Required queue. An Admin's own submitted payment broadcasts to the network immediately, subject to that Admin's 2FA.
• Beneficiaries: a Clerk can add a beneficiary and select “Manual Approval (Skip KYC/KYB),” but if Dual Control is enabled for that setting in the System Role Settings, the beneficiary sits in Pending Approval until an Admin reviews and approves it from the Action Required queue.
• Wallet visibility: the Wallet & Liquidity Management section , balances, liquidity KPIs, and the full transaction ledger , is Admin Only by default. Clerks only see it if Deposits or Withdrawals visibility is specifically enabled for them in the Team Role Settings. That opt-in governs viewing the section , the guide documents the wire and blockchain deposit/withdrawal flows themselves as Admin Only, and doesn't specify that this same toggle lets a Clerk initiate one.
• Blockchain withdrawals: these are restricted to destination addresses that have already been whitelisted and verified in System Settings, independent of who initiates the transfer.
• Dashboards: the Admin Dashboard shows a company-wide Action Required queue and a Recent Activity Feed covering every user's actions. The Clerk Dashboard is scoped to “My Pending Items” , that Clerk's own submissions awaiting approval , and a personal activity history, not a company-wide view.
• 2FA reset: only a Treasury Admin can reset a Clerk's two-factor authentication, via the Team Management tab. An Admin who loses their own 2FA device has to go through AlphaPoint (APG) Support for identity re-verification rather than having another Admin reset it directly , a deliberate extra step around the platform's most privileged accounts.

That's the documented foundation: two roles, a maker-checker pattern on payments and certain beneficiary approvals, and three separate configuration settings , the Role Settings (payment threshold), the System Role Settings (beneficiary Dual Control), and the Team Role Settings (Clerk wallet visibility). The guide doesn't spell out a standalone rule restricting who can change these settings; that Admins own them is a reasonable inference from Admins holding “high-level configuration” generally, not a separately documented permission. What the guide also doesn't include is a third or fourth named system role , there's no distinct “CFO” or “Controller” role in the product today, and no documented granular permission that lets a company give someone Clerk-level visibility while explicitly blocking that same Clerk from ever initiating a payment. Both of those are things a company has to design around using the two roles and the settings above, not features the platform names directly.

Mapping business roles onto Admin and Clerk

Because AlphaPoint's platform has two roles, a company with a CFO, a Controller, a Head of Treasury, and a payments team has to decide deliberately how those business functions map onto Admin and Clerk. Everything in this section is a segregation-of-duties model finance teams commonly build on top of a two-tier permission system, not a documented AlphaPoint feature , it's a recommended way to use the roles and settings described above, adapted to what the platform can actually enforce.

A reasonable starting model looks like this:

• Clerk / Payment Operator: the people doing day-to-day operational work , initiating payments against screened beneficiaries, entering new beneficiary records, and generating invoices. They should not also hold Admin rights, or the separation stops meaning anything.
• Controller / Treasury Manager (Admin): usually the primary approver , the person who reviews the Action Required queue, releases Clerk-submitted payments and beneficiary approvals, and owns reconciliation. AlphaPoint's own article on the first 48 hours of running a treasury recommends setting the payment threshold to mirror whatever dual-approval threshold the company already applies to wires and ACH, rather than inventing a new figure for stablecoins. That's a business-process recommendation from AlphaPoint's published content, not a rule the platform itself enforces , but it's a sensible default, and this person is typically best positioned to own the decision.
• Head of Treasury / Head of Digital Assets (Admin): in a larger organization, a second Admin who can review or escalate above the Controller , useful so the Controller isn't the only person who can both configure thresholds and approve against them.
• CFO (Admin, used sparingly): best practice is to give the CFO Admin access for escalation, oversight, and the ability to review the company-wide activity feed , not to make the CFO the routine approver for every payment. A CFO who rubber-stamps daily transactions loses the independent check a Controller-level review is supposed to provide.
• Finance reviewer with no payment authority: if a company wants someone who can see balances and transaction history but should never initiate a payment, that isn't a distinct role AlphaPoint documents today. It would need to be approximated with a Clerk given Deposits/Withdrawals visibility, understanding that Clerk-level access technically includes payment-initiation ability unless the company's own policy , not a platform control , says otherwise. Confirm current granularity with your AlphaPoint contact if this exact split matters to your control design.

Role × responsibility matrix

The table below maps common treasury responsibilities to a typical business owner and to what AlphaPoint's documentation confirms about which system role can perform it. “Typical business owner” is a governance recommendation; “AlphaPoint role required” and “Documented basis” reflect the product guide directly.

Why the risk changes as volume, headcount, and beneficiaries grow

Under 25 payments a month, one person, and a handful of beneficiaries, the risk of a control gap is real but bounded. Every payment is small enough, and the volume low enough, that a mistake or an unauthorized transfer is unlikely to go unnoticed for long. That changes on three axes at once as a treasury scales:

• Transaction volume and value: more payments and larger dollar amounts mean a single unauthorized or duplicated transfer costs more and is easier to bury inside legitimate activity.
• Headcount: every additional person who can touch the treasury is another potential single point of failure if roles aren't separated, and another person whose access needs to be reviewed and eventually revoked.
• Beneficiary count: a registry of a few trusted counterparties is easy to keep mentally sound. A registry of hundreds, added by multiple Clerks over time, needs a documented approval step , which is exactly what the Dual Control setting on beneficiary approval is for.

None of this means Admin headcount needs to match total headcount , the opposite is usually true. It means the ratio of who can initiate versus who can approve, and how tightly thresholds are set, should be revisited as the numbers move, not configured once at onboarding and left alone.

Practical decisions to make early, not after a problem

A few configuration decisions are easier to get right before volume grows than to retrofit afterward:

• Set the Payments Approval Threshold to match existing policy, not a number invented for stablecoins. If the company already requires a second sign-off above a certain dollar amount for wires, use that same figure rather than picking a new one specific to the stablecoin treasury.
• Default beneficiary approval to Dual Control. Letting a Clerk both add a beneficiary and mark it approved without review removes the one structural check the platform offers against an unauthorized or mistyped destination getting whitelisted.
• Appoint more than one Admin from the start. A single Admin is a single point of failure for every threshold decision, every payment approval, and every 2FA reset , and it means no one is actually checking that Admin's own submitted payments, which broadcast on their 2FA alone.
• Decide Clerk wallet visibility deliberately. Turning on Deposits/Withdrawals visibility for Clerks makes operational sense if they need to know funding status, but it also means giving up the default restriction that keeps company-wide liquidity visible to Admins only. Make that trade-off on purpose.

Conclusion

None of this is a one-time setup task. As a stablecoin treasury moves from a handful of payments a month to a real operating process, who is allowed to do what is a governance decision that needs periodic review , new hires get access, former employees need it revoked, and thresholds set for a smaller operation stop making sense at ten times the volume. AlphaPoint Treasury's Admin/Clerk structure, its Action Required queues, and its threshold and Dual Control settings give a company the mechanism to enforce a segregation-of-duties model. Designing that model , who is a Controller-level approver versus a payment operator, where the CFO sits, and how thresholds are set , is a decision finance leadership has to make on purpose.

For a structured look at where a treasury's controls already hold up and where they don't, AlphaPoint's Stablecoin Treasury Risk Map walks through custody, approval workflows, and reconciliation as a short self-assessment. Teams further along can book time directly with the AlphaPoint team to review role and threshold configuration for their specific volume and headcount.

Frequently Asked Questions

Does AlphaPoint Treasury support more than two user roles?

Not today. The documented RBAC model has two system-level roles , Treasury Admin and Treasury Clerk. Business-level distinctions such as CFO, Controller, or Head of Treasury are mapped onto these two roles rather than existing as separate platform roles.

Can a single Admin move company funds without anyone else reviewing it?

Per the documented workflow, yes for that Admin's own submissions: a payment an Admin initiates broadcasts to the network immediately, subject to that Admin's own 2FA, rather than automatically routing to a second approver the way a Clerk's payment does above threshold. Companies wanting a two-person check on every payment, including Admin-originated ones, need to build that into their own policy , for example, by appointing more than one Admin , rather than relying on the platform to enforce it automatically.

Who can reset a Clerk's two-factor authentication if they lose their device?

Only a Treasury Admin, through the Team Management tab. Admins cannot self-reset this way; an Admin who loses their own 2FA device needs to go through AlphaPoint (APG) Support for identity re-verification.