MooChedda Trust and Fiduciary

Trust Is Not a Promise. It's a Policy.

Establish Trust. Define Authority. Govern Every Transaction.

Most financial systems protect the money. Far fewer protect the authority to move it. MooChedda Trust and Fiduciary defines who may act, under which rules and with whose approval, before a single asset moves. Then it keeps a tamper-evident record of every decision.

Create Your MooChedda Account Explore How MooChedda Works

Already a member? Sign in to your institution.

TRANSFER · INTENT Awaiting authorization
$12,400,000.00 USDC
Treasury walletOnboarded beneficiary
Large Transfer PolicyOver $10M · 3 of 5 MPC signers + admin countersign
  • Destination passed sanctions screening and compliance sign-off
  • Initiator cannot approve their own transfer
  • Each approval needs a fresh authenticator code
  • Execution locked until every requirement is met
Illustration of how a transfer waits on policy. Thresholds shown are the platform's default Large Transfer policy.
  • Fail-closedNo matching policy means the action is refused
  • 7 signing policiesVersioned defaults for every new institution
  • 2FA on every approvalMandatory for all operators and administrators
  • Hash-chained audit trailAppend-only and independently verifiable

Trust-centered transactions

Before You Move Money, Establish Trust.

A transaction is the last step of a relationship, not the first. By the time money moves, the important questions should already have been answered: who the parties are, who is responsible, who has authority, and which rules apply.

Conventional systems usually ask those questions at the moment of payment, or not at all. MooChedda turns them into structure that exists before the transaction does. Roles, approval thresholds, verified destinations and governance rules are set up in advance and enforced automatically. Changing them takes approval from other people.

The result is a simple principle: if the rules have not been satisfied, the transaction does not execute.

What trust is built from

MooChedda makes each of these explicit, so that none of them is merely assumed.

  • Parties
  • Relationships
  • Responsibilities
  • Authority
  • Permissions
  • Conditions
  • Transaction policies
  • Approval requirements
  • Accountability
  • Documentation

The problem

Who Has the Authority to Move Your Money?

Companies, investors, trustees and trading partners move money, digital assets and obligations every day. Much of that activity still rests on assumptions nobody has written down.

What many transaction systems quietly assume

  • The platform is secure.
  • The administrator can be trusted.
  • The person authorizing a transaction is who they claim to be.
  • The destination is correct.
  • The transaction rules cannot be manipulated.
  • Employees and privileged users will not abuse their access.
  • A compromised account cannot initiate unauthorized transactions.
  • Counterparties will honor their obligations.

The real gap: execution and governance live apart

In most systems, the machinery that executes a payment and the rules that govern it are separate concerns. The rules sit in policy documents, email threads and people's memories. Execution sits in software that does whatever an authenticated user tells it to.

When those two drift apart, one stolen credential, one over-privileged account or one quietly edited destination can be enough to move funds.

Financial security takes more than protecting passwords, wallets and private keys. It means protecting the authority to act.

Questions worth asking about any system that moves your money

  • Who actually has the authority to move your money?
  • What happens if the person authorizing your transaction is compromised?
  • Can someone change the rules after a financial relationship has been established?
  • Are multiple approvals required for significant transactions?
  • Who is accountable when something goes wrong?
  • Do you know exactly who initiated, approved and authorized your transaction?
  • Is your money protected by more than a password?

A real-world warning · October 29–30, 2026

Billions Can Move Without a Private Key Being Stolen. Is Your Transaction Protected?

The October 2026 Binance incident shows why protecting digital assets alone is not enough. The authority to initiate, approve and execute transactions has to be protected too.

≈ $6.3B Impact initially estimated by Binance
≈ $3B Frozen by stablecoin issuers and partners within a day, per Binance and issuers
0 Evidence of wallet private-key leakage found, according to Binance

“Binance's initial investigation suggests that the security incident may involve a compromised DevOps engineer's laptop, which allowed an attacker to gain access to a service container and submit unauthorized withdrawal transactions. We have found no evidence of any wallet private key leak.”

Binance, official statement, October 29, 2026

How an incident like this unfolds: four stages

  1. Stage 1

    Access

    An attacker gains a foothold through compromised infrastructure, credentials or privileged systems.

    Reported: Binance said the entry point may have been a compromised DevOps engineer's laptop.

  2. Stage 2

    Authority

    Existing privileges or operational processes give the intruder a path to sensitive functionality.

    Reported: access to a service container. Co-CEO Richard Teng said the attacker “did not simply use one engineer's permissions”, and Binance later said it had “uncovered additional points of breach.”

  3. Stage 3

    Execution

    Unauthorized transaction requests are submitted and processed by systems that treat them as legitimate.

    Reported: unauthorized withdrawal transactions. Elliptic said the attacker “appears to have been able to get Binance's own systems to sign transactions.”

  4. Stage 4

    Consequences

    Assets are lost even though the underlying private-key protection held.

    Reported: withdrawals suspended, roughly $3 billion frozen, and Binance said it would cover losses from its SAFU fund and company funds.

The lesson

A platform can protect its private keys and still suffer unauthorized transactions if privileged access, operational infrastructure, authorization workflows or execution controls are compromised. In Elliptic's words about this incident and the 2025 Bybit theft: “it was the infrastructure and people around the wallets that were compromised, not the cryptography.”

Lessons from the incident

Security Protects Your Assets. Governance Protects the Authority to Move Them.

What if the rules governing a transaction were set before the transaction began, and no single laptop, login or engineer could satisfy them alone?

We don't claim MooChedda would have prevented the Binance incident. Every system depends on the integrity of the infrastructure it runs on. What follows are controls that can reduce comparable risks, and whether each is available in MooChedda today.

Operational available in the platform now Partial available in part
Operational

Strict access policies

Team members join only by single-use invitation, every member holds one of ten defined roles, and authenticator enrollment is mandatory before anyone reaches the application.

Operational

Separation of duties

Initiator, approver and settlement roles are mutually exclusive. Auditors hold no operational role. Initiators can't approve their own transfers.

Operational

Independent transaction authorization

Approvals come from other people, each with their own authenticator code and their own signing key, cryptographically bound to the exact transaction.

Operational

Transaction limits

Value bands select the policy. Larger transfers need more signers and, above $10M by default, a separate administrator countersign. Rolling daily, weekly and monthly spending caps stop anything above the limit.

Operational

Approved destinations

Funds go only to wallets that passed sanctions and risk screening, were signed off by a compliance officer, and have waited out their cooling-off period.

Operational

Privileged access monitoring

Every sign-in is recorded with its IP address (and location, where lookups are enabled), and administrator actions are audited. Unusual sign-ins raise alerts automatically, rated higher for owners and admins.

Operational

Transaction anomaly detection

AML rules flag velocity, high-risk geography, structuring and risky wallets. Operator analytics flag unusual hours, volumes and sign-in patterns. Both place mandatory holds.

Operational

Tamper-evident audit records

An append-only, SHA-256 hash-chained log with a timestamp attestation on every entry. Edits made by bypassing the database are detected on verification.

Operational

Emergency suspension

An Emergency Freeze, requiring unanimous CEO, CRO and Board Chair approval, pauses affected activity. A critical AML alert requests a freeze automatically.

Introducing MooChedda Trust and Fiduciary

Don't Just Transact. Establish Trust Around the Transaction.

MooChedda Trust and Fiduciary is a governance, custody-operations and compliance platform for institutions that administer assets on behalf of others. It brings parties, roles, authority, policy, approvals and records into one structured environment, so that trust is something the system enforces rather than something people assume.

Members & roles

Invite operators by single-use link and assign roles and executive designations (CEO, CFO, CTO, CRO, COO, Board Chair). Separation-of-duties rules are checked on every assignment.

Governance & policies

Seven versioned signing policies decide who may approve what, and how many approvals each action needs. Policies change only through an approved governance request.

Transactions & signing queue

Transfer intents wait in a prioritized signing queue with progress for each signer, SLA timers and countersign stages. Nothing settles until its policy is satisfied.

KYC / AML & compliance

Encrypted client KYC, beneficial-owner mapping, PEP flags, OFAC/EU/UN sanctions screening, AML rules, case management, and CTR, SAR, travel-rule and KYC report exports.

Cold storage ceremonies

Vault withdrawals require board approval and a five-step, dual-control offline signing ceremony. The signed payload is verified against the vault's registered key.

Audit trail

Every action is written to an append-only, hash-chained log that any authorized auditor can verify from the application.

Live dashboard & orchestration

Assets under custody by network, the signing queue, route health with automatic failover, and alerts, updated live.

Exchange custody (MTFX)

Link client or omnibus custody accounts to MooChedda's MTFX trading platform with one-time link codes. Every release still passes the same policies.

An important distinction

MooChedda Trust and Fiduciary is software. It supports trust governance and transaction authorization. It does not, by itself, create legal relationships or regulated services.

ConceptWhat it means here
Software-supported trust governanceProvided. Roles, policies, approvals and records configured and enforced by the platform.
Transaction authorizationProvided. Multi-party, authenticated, cryptographically signed approvals that are enforced before execution.
Fiduciary principlesSupported. The platform helps put loyalty, care, authority limits and accountability into practice. It doesn't perform those duties for you.
Legally established fiduciary dutiesNot created by the platform. These arise from law, contracts and appointments outside the software.
Formal trust arrangementsNot created by the platform. A legal trust requires proper legal instruments under the applicable jurisdiction.
Regulated financial servicesNot claimed. MooChedda Inc. does not hold itself out on this site as a bank, licensed trustee, fiduciary, escrow agent, custodian or other regulated institution. Any regulated services are the responsibility of the member institution and its licenses.

Why fiduciary principles matter

When Someone Acts on Your Behalf, Their Authority Should Have Edges.

A fiduciary relationship exists when one party manages assets or makes decisions for another. The law generally expects a fiduciary to act with loyalty and care, within the authority granted, managing conflicts of interest, and in the interest of the person the duty is owed to. These are old ideas. MooChedda helps make them operational.

01

Loyalty

Act in the interest of the party the duty is owed to, not your own.

In the platform: funds go only to destinations that compliance has screened and approved, and every movement records its beneficiary.

02

Care

Exercise the diligence a prudent person would in the same position.

In the platform: KYC, sanctions and AML screening run before money moves. Mandatory holds apply when something is wrong.

03

Acting within authority

Do only what you were empowered to do, and nothing beyond it.

In the platform: roles and value-banded policies decide who may initiate and approve. Anything no policy covers is refused.

04

Managing conflicts

No one should sit on both sides of a decision.

In the platform: initiators can't approve their own transfers, the countersigner must be someone else, and policy proposers can't approve their own changes.

05

Accountability

Be able to show what you did, when and why.

In the platform: signed approvals and a tamper-evident audit trail, with read-only auditor access for independent oversight.

What MooChedda solves

Eight Ways Transactions Go Wrong, and the Structure That Answers Each.

Problem 1

Unauthorized transactions

Compromised credentials or misassigned privileges let someone initiate a transfer they should never have been able to start.

Operational

Mandatory 2FA, role-based permissions and a policy match for every transfer. A fresh authenticator code is needed for every approval, so a stolen password alone authorizes nothing.

Problem 2

Centralized control

One administrator, employee or compromised account holds enough authority to move funds alone.

Operational

Separation of duties enforced on every role assignment, m-of-n approvals, a separate countersign for large transfers, and unanimous approval for emergency actions.

Problem 3

Undefined trust relationships

People enter arrangements without defining who is responsible for what.

Operational

Institutions, members, roles, executive designations, KYC-verified clients and onboarded beneficiaries are explicit records, not assumptions.

Problem 4

Lack of accountability

Nobody can say for certain who initiated, approved, changed or executed an action.

Operational

Every approval is signed with the approver's own key over the transaction digest and written to the hash-chained audit log in the same database transaction.

Problem 5

Transaction manipulation

Destinations, amounts or approval rules are quietly altered.

Operational

Approvals sign a digest of the exact transaction. Destinations must be onboarded through compliance. Policy edits need two other governors and create a new version.

Problem 6

Counterparty risk

Businesses regularly transact with people and organizations they don't know.

Partial

Client KYC, beneficial-owner mapping, PEP flags, sanctions and wallet-risk screening, with travel-rule details for counterparty VASPs. Automated PEP data feeds are an integration point.

Problem 7

No clear governance

Systems execute payments without defining who has the authority to approve them.

Operational

Governance comes first. Every action type, whether transfer, cold withdrawal, onboarding, freeze or policy change, maps to exactly one active policy, or it is refused.

Problem 8

No predefined transaction rules

Disagreements about limits and approvals only surface after something goes wrong.

Operational

Every institution starts with seven default policies on day one. Thresholds and approver pools are visible to members before any transfer is made.

Security architecture

Security Is Not Something You Add Later. It Starts With Policy.

Transaction security should be designed into the relationship before money moves. Below are twenty controls we hold ourselves to, each checked against what the platform actually does today. Open any control to see the threat, the policy, the protection and what happens on a violation.

Operational All twenty controls are available in the platform today.
  1. 01Identity verification before sensitive privilegesOperational
    Threat
    An impostor or unvetted account gains the ability to act.
    Policy
    New institutions wait for platform review before they can operate. Members join only through single-use invitations, and every operator must enroll an authenticator before reaching the application. Clients are KYC-verified by compliance and re-verified every 12, 24 or 36 months depending on risk tier.
    Protection
    Nobody gets operational privileges from an email and password alone.
    On violation
    Unenrolled sessions are confined to enrollment. Unreviewed or suspended institutions are refused.
  2. 02Role-based permissionsOperational
    Threat
    Users perform actions outside their job.
    Policy
    Ten roles (owner, admin, initiator, approver, settlement, compliance, board, custodian, auditor, viewer), each with an explicit permission set.
    Protection
    Each person can do their part and nothing more.
    On violation
    The request is refused and the missing permission is named.
  3. 03Least-privilege accessOperational
    Threat
    A compromised account exposes far more than its owner needs.
    Policy
    Auditors and viewers are read-only. Encrypted KYC data is decrypted only for compliance officers, and every view is audited. Only owners can grant owner or admin roles.
    Protection
    Limits the damage any single account can do.
    On violation
    Access is refused.
  4. 04Separation of dutiesOperational
    Threat
    One person both creates and approves a payment.
    Policy
    Initiator, approver and settlement roles are mutually exclusive, and auditors hold no operational role. Initiators and auditors can't hold MPC signing nodes.
    Protection
    Fraud requires collusion, not just one bad actor or one stolen login.
    On violation
    The role assignment or approval is refused.
  5. 05Multi-party transaction approvalOperational
    Threat
    A single signature moves significant value.
    Policy
    Defaults: up to $5M needs 2 of 3 operations approvers (auto-approved under $1M). $5M–$10M needs 3 of 5 MPC signers. Over $10M adds a separate admin countersign. Cold storage needs 2 of 3 board members plus an offline ceremony.
    Protection
    The higher the value, the more independent people must agree.
    On violation
    The transaction stays pending and never executes.
  6. 06Configurable transaction limitsOperational
    Threat
    Large transfers move with the same ease as small ones.
    Policy
    USD value bands select the governing policy. Thresholds, auto-approval limits and approver counts are configurable, but only through governance. Rolling 24-hour, 7-day and 30-day spending caps can be set for the whole institution or for each client, also only through governance.
    Protection
    Risk-proportionate approval without slowing routine activity, and a ceiling on how much can leave in any period, even through many small transfers.
    On violation
    The transfer is escalated to the stricter policy. If no policy covers it, it is refused. A transfer that would take a period's total over a cap is refused before it reaches the approval queue.
  7. 07Approved wallet and destination restrictionsOperational
    Threat
    Funds are redirected to an attacker's address.
    Policy
    Destinations must complete New Wallet Onboarding: sanctions and risk screening, compliance-officer sign-off, then any cooling-off period the institution has set.
    Protection
    Money can only go where it has already been verified to go.
    On violation
    The transfer is refused at creation.
  8. 08Immutable, tamper-evident policy recordsOperational
    Threat
    Rules or history are quietly rewritten.
    Policy
    Every policy change creates a new version, and transactions record the version they ran under. Audit entries are hash-chained with an HMAC attestation, database triggers block updates, and retention triggers refuse deletion of records younger than five years.
    Protection
    You can prove what the rules were at the moment of every decision.
    On violation
    Chain verification detects the break.
  9. 09Reauthentication for sensitive actionsOperational
    Threat
    A hijacked session approves transactions.
    Policy
    Approvals, countersigns, cancellations, ceremony steps and link codes each need a fresh authenticator code, and codes can't be replayed.
    Protection
    Possession of a session isn't possession of authority.
    On violation
    The action is refused.
  10. 10Device and session securityOperational
    Threat
    Stolen session tokens, or stale sessions on lost devices.
    Policy
    Sessions are stored server-side with hashed tokens, sent by header only (no cookies), and expire after 8 hours by default. Enrolling a new authenticator signs out every other session. Role changes sign the member out. Every sign-in is recorded with its IP address and, where enabled, its location.
    Protection
    Shrinks the window in which a stolen token is useful.
    On violation
    The session is rejected and the user must sign in again.
  11. 11Transaction and operator anomaly detectionOperational
    Threat
    Unusual activity goes unnoticed until it is too late.
    Policy
    AML rules for velocity, FATF high-risk geography, structuring and wallet risk raise alerts and mandatory holds. Operator analytics compare each person with their own history: sign-ins from a new country or at an unusual hour, sign-ins from two countries within two hours, bursts of failed sign-ins, transfer volumes far above their usual level, and many approvals in a few minutes. Owners and admins are rated one level higher.
    Protection
    Suspicious transfers stop before execution for human review, including transfers started by an operator whose behavior has been flagged.
    On violation
    The transfer is held until compliance closes the case. A critical AML alert requests an Emergency Freeze.
  12. 12Cooling-off periods for high-risk changesOperational
    Threat
    An attacker adds a destination or loosens a policy and uses it immediately.
    Policy
    A configurable waiting period, 24 hours by default for new institutions, before a newly onboarded destination, an approved policy change or a new spending limit takes effect. Owners, admins, board members and compliance are notified, and any of them can object.
    Protection
    Gives legitimate members time to notice and object.
    On violation
    Transfers to the new destination are refused until the period ends. An objection, confirmed with a 2FA code, cancels the change.
  13. 13Independent verification of material changesOperational
    Threat
    One insider changes something important without review.
    Policy
    Policy changes need two governors other than the proposer. New destinations need compliance sign-off. Cold-storage moves keep the same two custodians throughout the ceremony.
    Protection
    Material changes always have a second pair of eyes.
    On violation
    The change stays pending and has no effect.
  14. 14Emergency transaction suspensionOperational
    Threat
    An attack in progress can't be stopped quickly.
    Policy
    Emergency Freeze requires unanimous CEO, CRO and Board Chair approval and pauses affected releases without failing them. The platform operator can also suspend an institution or user, revoking their sessions at once.
    Protection
    A deliberate, accountable way to stop activity.
    On violation
    Activity under the freeze is paused until a governed unfreeze.
  15. 15Comprehensive transaction monitoringOperational
    Threat
    Teams can't see what is in flight.
    Policy
    A live dashboard, a signing queue with SLA timers, route health probes with automatic failover, and role-targeted notifications.
    Protection
    Problems surface while they can still be acted on.
    On violation
    SLA breaches and route failures are flagged and alerted.
  16. 16Administrative accountabilityOperational
    Threat
    Administrators operate without oversight.
    Policy
    Platform and institution administrators use mandatory 2FA. Their decisions are written to the audit log. Admins can't countersign transfers they approved.
    Protection
    Privilege comes with a record.
    On violation
    The action is refused, and every attempt is recorded.
  17. 17Policy modification approvalOperational
    Threat
    Someone changes the rules after the relationship is established.
    Policy
    Policies change only through a governance request approved by two of the owners, admins or board members, excluding the proposer.
    Protection
    The rules stay fixed unless the governors agree to change them.
    On violation
    Direct edits aren't possible. The request waits for approval.
  18. 18Transaction authorization expirationOperational
    Threat
    Old, forgotten approvals are used much later.
    Policy
    Each policy sets an approval window: 24 hours by default for transfers, 48 hours for cold storage and 7 days for governance requests. Pending items also carry an SLA deadline, and sessions expire.
    Protection
    Partial approvals can't sit around waiting to be completed much later.
    On violation
    An item not fully approved in its window is expired and must be submitted again, with a new digest. Late approvals are refused.
  19. 19Revocation of compromised credentials and permissionsOperational
    Threat
    A known-compromised account keeps working.
    Policy
    Suspending a user or institution revokes their sessions immediately. Admins can reset a lost authenticator. Invitations and MTFX link keys can be revoked at once.
    Protection
    Access can be cut the moment you suspect something.
    On violation
    Revoked credentials are refused on their next request.
  20. 20Secure audit and reportingOperational
    Threat
    You can't prove what happened to a regulator, a client or a court.
    Policy
    Auditor access to the trail, one-click chain verification, CTR, SAR, travel-rule and KYC CSV exports, and an evidence feed to a connected GRC system.
    Protection
    Accountability you can demonstrate, not just assert.
    On violation
    Verification reports any break in the chain.

Policy and authorization architecture

Six Gates. No Shortcuts.

A transaction doesn't execute until every applicable requirement is satisfied. Select a gate to see what it checks, or send a transaction through and watch where it stops.

Identity: who is asking?

The requester must hold a live, server-side session established with a password and an authenticator code, and must belong to an active, platform-reviewed institution.

Stops: expired or revoked sessions, unenrolled accounts, suspended institutions.

Try it: send a transaction through the gates

Choose a scenario to see how the platform responds.

Simulation based on the platform's default policies. It runs in your browser and touches no live data.

How a MooChedda transaction works

Eight Steps From Relationship to Record.

The first four steps happen before any transaction exists. That is the point.

  1. 1

    Establish trust

    Identify the parties and their relationship.

    Register the institution and complete platform review. Onboard clients with KYC and beneficial owners.

  2. 2

    Define responsibilities

    Decide who manages, authorizes and oversees.

    Invite members and assign roles and executive designations. Separation of duties is checked automatically.

  3. 3

    Define authority

    Establish who can initiate, approve, manage and execute.

    Assign MPC signing nodes to signers, name countersigners, and appoint cold-storage custodians.

  4. 4

    Establish policies

    Set limits, conditions, restrictions and approval requirements.

    Review the seven default policies and propose changes through governance. Onboard approved destinations.

  5. 5

    Verify

    Check identities, transaction details, counterparties and the authorization required.

    Policy matching, destination checks, sanctions screening and AML rules run when the intent is created.

  6. 6

    Authorize

    Collect every approval the policy requires.

    Signers approve from the signing queue with their authenticator code. A countersign or offline ceremony follows where required.

  7. 7

    Execute

    Release only when every condition is satisfied.

    The settlement queue routes and releases the transfer and updates the custody ledger atomically.

  8. 8

    Document

    Keep a permanent record of activity, decisions and status.

    Hash-chained audit trail, verifiable from the app, with regulatory report exports.

A different philosophy

There's a Better Way to Transact.

Many good platforms offer some of these controls. The difference is where governance sits: in MooChedda it comes first, and it is part of the transaction rather than an add-on.

Common transaction approaches compared with MooChedda's trust-centered approach
DimensionCommon approachMooChedda Trust and Fiduciary
Trust established before transactingOften implied by account accessParties, roles and policies exist before any transfer can be created
Clearly defined rolesFrequently broad user or admin levelsTen roles plus executive designations
Defined responsibilitiesKept in documents outside the systemEncoded in permissions and approver pools
Policy enforcementVaries; sometimes manual reviewAutomatic and fail-closed: no matching policy, no action
Multi-party authorizationAvailable on some platforms, often optionalBuilt into every default transfer policy
Transaction limitsUsually per-account capsValue bands that escalate approval requirements
Destination restrictionsAllowlists offered by some providersMandatory onboarding with screening and compliance sign-off
Documented approval historyActivity logs of varying depthSigned approvals bound to the transaction digest
Governance and oversightRule changes often a settings changeRule changes need two other governors and create a new version
AccountabilityDepends on log retention and integrityHash-chained, attested and retention-protected audit trail

Real-world transaction examples

What Governance Looks Like in Practice.

Five illustrative scenarios. They show how the platform's controls apply. They are not offers of regulated trust administration, legal fiduciary services, custody or escrow.

Scenario

A company pays a supplier $250,000

An accounts-payable clerk receives an urgent email asking to send the next supplier payment to a new wallet.

  1. Verified destination. The new wallet can't be paid until it completes New Wallet Onboarding: sanctions screening, risk scoring and a compliance officer's sign-off. A spoofed email can't skip that step.
  2. Defined authority. The clerk holds the initiator role and can create the intent, but can never approve it.
  3. Tailored limits. The default Daily Settlement policy auto-approves screened transfers under $1M. A company that wants two people on every supplier payment proposes lowering that threshold. Two other governors approve the change, and a new policy version takes effect.
  4. Multiple approvals. Under that policy, two operations approvers sign the transfer with their own authenticator codes.

A fraudulent destination change becomes a visible governance event instead of a silent payment.

Who should use MooChedda

Built for Anyone Who Moves Value on Someone's Behalf.

Membership is held by institutions: companies, trusts, family offices, funds and firms. Each registrant becomes the owner of their organization's workspace and invites the people who act for it.

The problem
Personal wealth is increasingly held in digital assets protected by one password or one seed phrase, and often managed with help from others.
Why existing processes fall short
Consumer apps optimize for speed. Whoever holds the login holds the money.
How MooChedda helps
Individuals take part as KYC-verified clients of a member institution, whose transfers are governed by policy. Those who manage significant wealth can register their own family office or holding entity.
Why define it first
Deciding who may act for you is far easier before an emergency than during one.

Why join

Your Next Transaction Deserves More Than a Promise.

Whether you are an individual, business, investor or fiduciary, the way you transact matters. MooChedda Trust and Fiduciary brings a trust-centered approach to financial relationships, defined authority, transaction policies and accountability.

  • Establish trust before transacting
  • Define responsibilities and authority
  • Create structured relationships
  • Establish transaction policies
  • Improve transaction accountability
  • Reduce exposure to unauthorized activity
  • Build confidence between counterparties
  • Maintain transaction documentation
  • Build a foundation for more responsible transactions
Create Your MooChedda Account Explore How MooChedda Works

What happens when you apply

  1. Register your organization. Legal name, jurisdiction, optional LEI, and your details. You become its owner.
  2. Secure your account. Enroll an authenticator app right away. It's mandatory for every operator.
  3. Platform review. MooChedda reviews new institutions before they can operate.
  4. Build your structure. Invite your team, assign roles, review your seven default policies and onboard destinations.

Already invited by your organization? Use the link in your invitation email.

Pricing

One Price. Everything Included.

One monthly subscription per institution covers the whole platform, every operator and every transaction. There are no per-seat charges and no per-transaction fees from MooChedda. The full list of what is included is below the price.

MooChedda Trust and Fiduciary

$2,500per month, per institution

  • Every member of your team, with roles and separation of duties
  • Seven versioned signing policies and governed policy changes
  • Multi-person approvals, each confirmed with its own 2FA code and signed
  • Destination onboarding, sanctions screening and AML monitoring
  • Client KYC, beneficial owners and regulatory report exports
  • Cold-storage offline signing ceremonies and Emergency Freeze
  • Hash-chained audit trail, GRC integration and MTFX custody links
Create Your MooChedda Account

Optional add-on

AWS CloudHSM key protection

+$2,500per month, up to 16,666 keys

Your institution gets its own MooChedda environment hosted inside AWS, with its own AWS CloudHSM cluster that no other client shares. Your keys are generated inside the HSM and can never be exported from it. Every signature is made inside the HSM.

  • Everything in the base plan, on your dedicated AWS environment
  • Every operator approval key (ECDSA P-256), from day one
  • Every MooChedda-network wallet key (secp256k1)
  • Up to 16,666 keys held in the HSM. Each further block of up to 16,666 keys is another $2,500 per month.
  • Approvals stop, rather than fall back to software keys, if the HSM is unreachable

Each operator approval key and each MooChedda-network wallet key counts as one key, including retired keys kept so past approvals can still be verified. Without the add-on, keys are encrypted at rest with AES-256-GCM on tf.moochedda.com. Your AWS environment is a separate account. If you are already a member, you set up your team and policies there and transfer funds to new wallets; your history stays on your existing account.

What your $2,500 a month covers

The subscription is your institution's licence to the whole platform, hosted and run by MooChedda. Nothing below is an extra charge.

Your whole team

  • As many operators as your institution needs, with no per-seat fee
  • Single-use invitations, ten defined roles and executive designations
  • Separation-of-duties checks on every role assignment
  • Mandatory authenticator (TOTP) sign-in, session control and sign-in records

Governance and approvals

  • Seven versioned signing policies, changed only through approved governance requests
  • Multi-person approvals, each confirmed with a fresh 2FA code and cryptographically signed
  • Administrator countersign on large transfers ($10M and above by default)
  • A prioritized signing queue with SLA timers

Transactions and custody

  • Unlimited transfer intents, with no per-transaction fee from MooChedda
  • Settlement queue with route health checks and automatic failover
  • Custody ledger and a live dashboard of assets under custody by network
  • MooChedda-network wallets and MTFX exchange custody links

Compliance tools

  • Encrypted client KYC, beneficial-owner mapping and PEP flags
  • OFAC, EU and UN sanctions screening of every destination
  • AML rules, mandatory holds and case management
  • CTR, SAR, travel-rule and KYC report exports

Cold storage and emergencies

  • Board-approved vault withdrawals
  • Five-step, dual-control offline signing ceremonies, verified against the vault's key
  • Emergency Freeze with unanimous CEO, CRO and Board Chair approval

Audit and records

  • Append-only, hash-chained audit log with one-click verification
  • Approvals, transactions and compliance records kept for at least five years
  • Read-only auditor access for your internal or external auditors
  • An evidence feed to your GRC system

Hosted and maintained

  • Runs at tf.moochedda.com, with nothing to install
  • Hosting, database and platform operations run by MooChedda
  • New features and fixes as they ship, at no extra cost
  • Live notifications and in-app alerts

Not included

  • Blockchain network fees, which the networks charge
  • The AWS CloudHSM add-on and your dedicated AWS environment, unless you choose it ($2,500 per month per block of up to 16,666 keys)
  • Running your own MPC signing network or offline signing devices
  • Services from third-party providers you connect, such as your GRC system or a PEP data provider
  • Legal, trustee, fiduciary or compliance services. MooChedda provides software and is not your trustee or adviser.
Billing
Invoiced monthly in advance, from the day your institution is activated
Commitment
Month to month. Either side can end it on 30 days' written notice.
Price changes
At least 30 days' notice before any fee change

Blockchain network fees are charged by the networks themselves and are separate. Prices are in US dollars and exclude taxes. Billing starts when your institution is activated after platform review.

FAQ

Questions, Answered Plainly.

What is MooChedda Trust and Fiduciary?

A platform from MooChedda Inc. for institutions that administer assets on behalf of others. It combines governance (roles, policies and multi-party approvals), custody operations (wallets, settlement and cold-storage ceremonies), compliance (KYC, sanctions screening and AML) and a tamper-evident audit trail. Its purpose is to make sure every transaction is authorized under defined rules before it executes.

What does MTFX stand for?

MTFX is MooChedda's multi-asset trading platform, a separate MooChedda Inc. product at mtfx.moochedda.com, where people and member firms trade equities, ETFs, bonds, crypto, FX, futures and options from one account. Accounts held in MooChedda Trust and Fiduciary can be linked to MTFX with single-use link codes, so this platform acts as custodian for MTFX assets. Releases requested by MTFX still pass through this platform's signing policies and compliance checks.

What does trust-based transacting mean?

It means settling the who, what and how of authority before money moves: who the parties are, who may initiate, who must approve, which destinations are allowed and which limits apply. The transaction is then checked against those rules automatically and executes only if they are satisfied.

What is a fiduciary?

A fiduciary is a person or organization that manages assets or makes decisions on behalf of someone else, and owes that person duties such as loyalty, care, acting within granted authority and avoiding or managing conflicts of interest. Trustees, executors, many asset managers and corporate directors are common examples. The exact duties depend on the law and the arrangement.

How does MooChedda support fiduciary principles?

It turns those principles into enforced controls. Authority limits become roles and policies. Care becomes screening and compliance holds. Conflict management becomes separation of duties and the rule that nobody approves their own request. Accountability becomes signed approvals and a verifiable audit trail. The platform supports people in meeting their duties. It doesn't perform those duties for them.

How are trust relationships established?

An organization registers and becomes a member institution after platform review. Its owner invites members by single-use invitation and assigns their roles and designations. Compliance onboards clients with KYC data, beneficial owners and risk tiers. Destinations become usable only after New Wallet Onboarding. Each of these is a recorded, attributable step.

How are transaction policies established?

Every new institution starts with seven default policies: Large Transfer, Standard Transfer, Daily Settlement, Cold Storage Access, New Wallet Onboarding, Emergency Freeze and Policy Governance. To change one, an owner, admin or board member proposes the change and two others approve it. The proposer can't approve their own change. Each approved change creates a new policy version.

Can multiple parties be required to approve transactions?

Yes, and by default they are. Transfers up to $5M need 2 of 3 operations approvers (auto-approved under $1M after screening). $5M to $10M needs 3 of 5 MPC signers, and over $10M adds a separate administrator countersign. Cold-storage withdrawals need 2 of 3 board members plus an offline signing ceremony, and an Emergency Freeze needs the CEO, CRO and Board Chair unanimously. Institutions can tighten these through governance.

How does MooChedda help reduce unauthorized transactions?

Through layers. A stolen password isn't enough because 2FA is mandatory and every approval needs a fresh code. One person isn't enough because of separation of duties and multi-party approval. An unknown destination isn't payable because destinations must be onboarded, and new ones wait out a cooling-off period. Spending caps limit how much can leave in a day, week or month. Unusual activity, by clients or by your own operators, triggers holds, and anything outside policy is refused. No set of controls can eliminate every risk, but these make a single point of compromise much less likely to succeed.

How is MooChedda different from a cryptocurrency exchange?

An exchange is a marketplace for buying and selling. MooChedda Trust and Fiduciary isn't a trading venue: it has no order books and no trading. It governs how an institution holds and moves the assets it administers. MooChedda's trading platform is MTFX, a separate product that can use this platform as its custodian.

Is MooChedda a bank?

No. MooChedda Inc. is not a bank, and nothing on this site claims a banking, trust-company, money-transmission or other financial license. Member institutions are responsible for holding whatever licenses their own activities require.

Does MooChedda hold or custody customer assets?

MooChedda Trust and Fiduciary is custody-operations software. Member institutions use it to administer client accounts, wallets and vaults and to govern how those assets move. For most networks, transactions are signed by an MPC signing network and offline signing devices operated by or for the institution, which the platform coordinates and verifies. For wallets on the MooChedda network that the platform generates, it stores the private key encrypted, or, for institutions on the AWS CloudHSM add-on, keeps it inside the HSM, and signs only transfers that have satisfied the institution's policy. Whether a custody service is offered to you, and by whom, depends on the member institution and its regulatory permissions. Nothing on this page is an offer of custody services by MooChedda Inc.

Can transactions be reversed?

Before release, yes. The initiator or an administrator can cancel a transaction while it is held, awaiting approval or countersign, awaiting an offline ceremony, or queued, and compliance can reject a held transaction. Once a blockchain transfer is confirmed, it generally can't be reversed by anyone. That is exactly why MooChedda puts its controls before execution.

What happens when a transaction violates a policy?

It doesn't execute. If no active policy covers it, it is refused outright. If the destination isn't onboarded, it can't be created. If it would exceed a spending cap, it is refused. Self-approvals, approvals by ineligible members and approvals after the policy's approval window has closed are rejected. AML findings and flagged operator behavior place a mandatory hold that only compliance can release, and a critical alert automatically requests an Emergency Freeze. Each of these outcomes is written to the audit trail.

Who can use MooChedda?

Organizations that administer assets: custodians, trust companies, family offices, asset managers, funds, corporate treasuries and trading firms, along with the people they invite. Individuals typically take part as clients of a member institution, or through an entity they control.

How do I create an account?

Go to Apply for membership. Enter your organization's legal name, its jurisdiction (two-letter ISO code), an optional LEI, your name, your work email and a password of at least 12 characters using three of: lowercase, uppercase, digits and symbols, and accept the Terms of Use and Privacy Policy. You'll then enroll an authenticator app. Your institution can operate once the platform has reviewed it. If your organization is already a member, ask its administrator for an invitation.

Are there transaction fees?

No. MooChedda charges one subscription of $2,500 per month per institution, with no per-seat or per-transaction fees. The optional AWS CloudHSM add-on, which gives your institution its own AWS-hosted environment and its own CloudHSM cluster, with your keys inside the hardware security module, is $2,500 per month more for up to 16,666 keys, and another $2,500 per month for each further block of up to 16,666 keys. Fees charged by blockchain networks themselves are separate. See Pricing.

What types of transactions does the platform support?

Digital-asset transfers recorded as Transfer, Wire Settlement, DeFi Settlement, Token Rebalance, FX Settlement, Client Withdrawal, Treasury Rebalance, Cold Withdrawal and Cold Sweep, plus deposit recording. Supported networks are Bitcoin, Ethereum, Arbitrum One, Optimism, USDC (Circle), Hyperledger Fabric, the MooChedda network and permissioned ledgers. Governance actions such as wallet onboarding, policy changes and freezes follow the same approval model. The platform isn't a card or bank-payment processor.

How does MooChedda document transaction approvals?

Each approval requires a fresh authenticator code and is signed with the approver's own key over a digest of the transaction: an Ed25519 key encrypted at rest, or, with the AWS CloudHSM add-on, an ECDSA P-256 key that never leaves the HSM. It is bound to their session and written to the audit log in the same database transaction, and database triggers make it immutable. The audit log is SHA-256 hash-chained with an attested timestamp on each entry, so it can be verified at any time from the application. Records are protected from deletion for at least five years.

Does creating an account automatically create a legal trust or fiduciary relationship?

No. Registering creates a software workspace for your organization. A legal trust requires proper legal instruments, and fiduciary duties arise from law, contracts or appointments, not from opening an account. MooChedda helps you govern and document relationships you have established. Consult qualified legal counsel about your obligations.

Establish Trust. Define Authority. Govern Every Transaction.

Join MooChedda Trust and Fiduciary, and let the rules protect the relationship before money moves.

Join MooChedda Trust and Fiduciary Sign in