Purchasing Permissions and Separation of Duties in a Coin Shop

Small teams still need separated decisions

Separation of duties is often misunderstood as a large-company requirement. In a coin shop, it is a practical way to prevent one mistake, compromised account, or dishonest act from moving both metal and money without another signal. NIST defines the principle as preventing one user from having enough privilege to misuse a system alone and notes that a two-person rule can enforce separation dynamically.

The goal is not to require two people for every routine purchase. It is to identify combinations of actions that create unacceptable risk and separate them at the right threshold. A trained buyer may handle ordinary intake, testing, and matrix pricing within limits. A second authorized person may be required for an unusual product, manual spot input, third-party payee, large amount, failed test, override, or same-day inventory adjustment.

Design around decisions, not job titles. “Manager” is too broad if it automatically grants every purchasing, payment, configuration, reporting, and user-administration right. Define what each role can view, initiate, approve, execute, reverse, and reconcile. Then assign people to roles based on current duties and competence.

Map the complete purchase transaction

List the actions from first contact through final close: create customer or seller, verify identity and authority, open lot, describe items, test, grade or categorize, capture spot reference, calculate offer, override price, approve, obtain acceptance, create payment, release payment, receive inventory, change location, remove a hold, make an adjustment, sell or transfer the item, and reconcile cash, bank, and inventory.

For each action, ask four questions. Can it create or change value? Can it release money? Can it move or make inventory available? Can it hide or correct evidence? The highest-risk combinations generally cross those boundaries. For example, a user who can both increase a purchase price and release payment can monetize an override. A user who can receive an item and approve an inventory write-off can conceal a shortage.

Include configuration. Changing spot sources, pricing matrices, approval limits, payment accounts, user roles, location definitions, or audit retention can be as consequential as approving one purchase. Administrative power should not be an invisible super-role given to whoever knows the password.

Build a role-permission matrix

Use verbs. A role may view purchase records, create intake, record tests, propose an offer, approve within a band, release a specific payment method, receive inventory, move inventory, adjust quantities, reconcile, export sensitive data, manage pricing rules, or administer users. “Purchasing access” hides too much.

Distinguish scope. Permissions can be limited by location, value, product, payment method, transaction state, customer relationship, or time. A show buyer may create purchases at one event but not change the central pricing matrix. A cashier may issue an approved check up to a limit but not alter the payee. A specialist may record grade and value evidence without releasing payment.

Document conflicts explicitly. The same person should not approve their own high-risk exception; change a payee and release the payment without review; count inventory and approve the unexplained adjustment; create a user and approve that user’s privileged role; or cancel a locked transaction and conceal the associated reversal. Enforce the conflict in the system where possible rather than relying on a policy memo.

Separate appraisal, offer, approval, and payment

These steps can occur quickly, but they should remain distinct events. The evaluator records identification, test results, grade or category, quantity, and valuation evidence. The buyer applies the approved purchasing rule and proposes an offer. The approver evaluates exceptions and authority. The payment user releases funds only from the accepted, approved record.

In a routine low-risk transaction, one trained employee may perform evaluation and offer within a defined matrix. Approval can be automatic because the rule—not the individual—sets the permitted range. When the employee departs from the rule, the system should require a reason and apply the appropriate second review.

Do not make the second person retype the transaction. Give them the evidence and the calculated impact. A meaningful approval shows original rule, proposed deviation, seller and payee, test status, item summary, payment method, prior related exceptions, and who initiated the request. The approver must be able to reject or return it without the initiator bypassing the decision through another screen.

Choose thresholds based on risk

Dollar value is one trigger, but not the only one. Add product risk, test confidence, serial mismatch, manual metal or unit entry, unusual fineness, first-time seller, represented party, cash or third-party payment, new bank destination, after-hours activity, remote transaction, negative margin, price override, repeated cancellations, and employee relationship.

Use tiered authority. A buyer may approve routine transactions to one limit, a manager larger or unusual transactions, and an owner defined strategic or exceptional cases. Keep limits in one controlled configuration with effective dates. Avoid posting sensitive thresholds where customers can use them to structure behavior, while ensuring employees know when escalation is required.

Aggregate related activity where risk policy requires it. Several smaller purchases, adjustments, or payments can create the same exposure as one large event. The system should help reviewers see related transactions without making a legal conclusion automatically. Qualified advisers should define any regulatory aggregation and reporting rules.

Make two-person control real

A second set of initials is not independent if the approver cannot see evidence, feels compelled to agree, or shares the same login. Require a distinct authenticated user. Prevent self-approval. Show the decision in context and record timestamp, result, comment, and version approved. If material fields change, invalidate the approval and require another.

For physical controls, define what both people must observe. A high-value purchase may require both to verify item identifiers and payment. A vault transfer may require sender and receiver counts. A large adjustment may require a blind recount. The second person should not merely watch the first person enter the expected number.

Schedule coverage so control exists when the shop is busiest. If no qualified approver is available, the transaction can wait, use a permitted remote approval, or proceed only under a documented emergency rule. Operational inconvenience is not a reason to make shared approval credentials routine.

Eliminate shared accounts

Every employee should use an individual account protected by strong authentication, preferably multi-factor authentication where supported. Shared “counter” or “manager” credentials destroy attribution and make timely offboarding difficult. A common workstation can still require individual sign-in or a quick secure role switch.

Do not share physical safe combinations, alarm codes, payment tokens, email accounts, or carrier credentials more broadly than needed. Digital and physical permissions should reinforce each other. A person who cannot approve a vault move in software should not be the only holder of the relevant physical access.

Prohibit credential sharing in policy and make the approved workflow usable enough that staff do not need it. If employees share because signing in takes too long, improve session and device design without removing identity. If they share because one role lacks necessary access, review the role rather than borrowing somebody else’s authority.

Control overrides and emergencies

Some small teams need a break-glass capability when an approver is unavailable or a system dependency fails. Define exactly who may use it, which actions it permits, required reason, time limit, notification, and next-business-day review. Make the override more visible than the normal path, not a hidden master password.

Capture the original restriction, user, time, transaction, stated reason, action taken, and financial or custody impact. Automatically notify the owner or designated reviewer. Expire temporary permissions. If the override modifies a price, payee, status, or inventory value, preserve the before-and-after record.

Track override patterns. Frequent use on the same shift may indicate poor staffing, unrealistic limits, broken integration, or intentional control avoidance. Fix the root cause. An emergency path that becomes normal is simply an undocumented permission model.

Review access through the employee lifecycle

Provision access from an approved role request that names location, responsibilities, start date, training status, and approver. Grant the minimum necessary access. Do not copy a senior employee’s account as a shortcut. Require completion of relevant procedures before enabling high-risk actions.

Update access promptly after promotion, transfer, leave, disciplinary restriction, role conflict, or departure. Disable rather than erase former users so their historical actions remain attributable. Revoke active sessions, credentials, tokens, shared systems, physical keys, alarm codes, and third-party vendor access according to the offboarding plan.

At least quarterly—and more often for high-risk roles—ask managers to attest that each person still needs each role. Review dormant accounts, excessive rights, temporary grants, shared credentials, service accounts, and users who can both initiate and approve conflicting actions. Compare permissions with actual usage; an employee who has not used a high-risk right may not need it.

Make each review produce evidence, not just a checked box. Give the responsible manager a current user-and-role report, a list of recent permission changes, and the date each privileged right was last exercised. Require a written decision for every exception: retain it with a business reason and named owner, narrow it to a safer role, or remove it by a specific deadline. After revocation, test a representative account to confirm the restriction actually took effect across the point-of-sale system, bullionOS, banking tools, marketplaces, and any connected vault or shipping workflow. Record who completed the review, who approved retained conflicts, and when the next review is due. This turns access certification into a repeatable control that an owner, auditor, or insurer can reconstruct later.

Log events managers can actually review

Record sign-in and authentication changes, role grants, pricing configuration, manual spot entries, offer overrides, approvals, payment changes and releases, inventory receipt and movement, hold removal, adjustments, cancellations, refunds, exports, and break-glass use. Logs should identify user, time, object, action, result, and meaningful before-and-after values.

Protect logs from the same users whose activity they record. A privileged administrator may need to manage users but should not be able to quietly erase audit history. Retention, access, export, and alert rules should follow the business’s legal, insurance, security, and accounting advice.

Review exceptions, not raw noise. Useful alerts include self-approval attempts, repeated rejected approvals, new payee plus payment, manual price outside limits, adjustment after a count, dormant privileged account use, bulk export, after-hours high-value activity, or a role change followed quickly by a sensitive action. Investigate context before drawing a conclusion.

Align the morning and closing controls

At open, review available approvers, temporary roles, unresolved purchasing exceptions, pending payments, and custody from the previous day. Ensure role coverage matches scheduled activity such as estate appointments, shows, transfers, or large customer pickups.

At close, compare initiated purchases with approvals, payments, inventory receipts, locations, and cash or bank events. Flag any user who completed an incompatible combination under an override. Confirm that no privileged session remains active on an unattended device and no temporary role extends past its need.

Monthly, combine permission and transaction data. Which users generate the most overrides? Which approvers approve unusually quickly or always agree? Which locations adjust inventory after one-person receipt? Patterns deserve review even when each individual transaction falls below a threshold.

A 30-day permission reset

1. Week 1: Map purchasing, payment, custody, adjustment, reconciliation, configuration, and user-administration actions.
2. Week 2: Build roles, scopes, conflicts, thresholds, and a two-person approval matrix.
3. Week 3: Assign individual accounts, remove shared access, train staff, and test normal and exception scenarios.
4. Week 4: Review logs, close permission gaps, document break-glass use, and schedule quarterly attestations.

Start with the actions that can move both value and evidence. A perfect enterprise role catalog is not required to separate the most dangerous combinations. Make the first model understandable, enforce it consistently, and improve it using observed exceptions.

Permissions should let a trained employee complete ordinary work confidently—and make extraordinary risk visible before metal or money leaves control.

Put roles and approvals inside the workflow

bullionOS supports individual accounts, operational roles, transaction history, inventory custody, payment states, and management visibility across the dealer’s daily work.

Connect this workflow in bullionOS

Bring this operating process into one connected dealer record. Explore Coin Dealer Software & POS, or visit the bullionOS dealer operations resource hub for related guides.