Part 1 covered who can be a holder. Part 2 covered how they get verified. Part 3 covers the question that comes up on every transfer: is this specific transaction allowed right now. The answer depends on a stack of rules that change on different clocks (regulatory, contractual, operational), and the reason ERC-3643 won is that it expresses every one of those rules as a swappable compliance module rather than baking them into the token contract. This part walks through the rule taxonomy, the on-chain enforcement primitive (canTransfer), and the revert-by-default semantics that make the machine safe.

The rule taxonomy

Per-token restrictions, applied to every transfer of the instrument. Both sender and receiver must be whitelisted (the precondition from Part 1). The receiver must sit in a jurisdiction the issuer is licensed to distribute into; for a Reg D 506(c) and 3(c)(7) wrapper like MONY or BUIDL, that means a qualified purchaser inside an approved jurisdiction set, with US persons subject to one rule and non-US persons to another. The receiver may need to clear a sophistication threshold (qualified purchaser, accredited investor, professional investor under MiFID II, accredited investor under MAS SFA section 4A). Volume caps may apply at the protocol level, though most institutional products handle velocity off-chain.

Per-investor restrictions, applied to a specific holder's balance. Lock-up periods bar outgoing transfers for the first N days after a primary subscription, common in private-credit and tokenised-equity products and used selectively in tokenised funds during initial distribution. Holding-period requirements oblige a minimum tenure before secondary transfer, often N days under Rule 144 for resales of restricted securities. Maximum-holding limits prevent any single beneficial holder from accumulating above a stated percentage of the float, controlling concentration risk and keeping the issuer below ownership thresholds that would trigger a reporting or licensing change.

Jurisdictional restrictions, applied as veto rules. Tokens cannot move to wallets associated with sanctioned jurisdictions (OFAC SDN, EU consolidated, UK OFSI). Some products run separate rule sets for US versus non-US persons, selected based on a claim on the receiver's OnchainID. A transfer that would move a US person into a position breaching Investment Company Act limits, or a non-US person into a position breaching a local distribution rule, fails the same way as a sanctions hit: the transfer reverts.

The canTransfer primitive

The token contract calls a single function on a separate compliance contract before executing. In the canonical ERC-3643 layout, the token's transfer path is roughly:

function transfer(address to, uint256 amount) public returns (bool) {
    require(identityRegistry.isVerified(to), "recipient not verified");
    require(
        compliance.canTransfer(msg.sender, to, amount),
        "transfer not compliant"
    );
    _transfer(msg.sender, to, amount);
    compliance.transferred(msg.sender, to, amount);
    return true;
}

Two things matter about this shape. First, the compliance check happens before any state change, which means a failed check produces a clean revert with no side effects on balances. Second, the compliance contract is a separate address whose implementation is upgradeable and whose modules can be added or removed without redeploying the token. The token sees compliance as a single boolean answer; the compliance contract is free to internally consult any number of rule modules to produce that answer.

A typical compliance contract aggregates rule modules and short-circuits on the first rejection:

function canTransfer(address from, address to, uint256 amount)
    external
    view
    returns (bool)
{
    for (uint256 i = 0; i < modules.length; i++) {
        if (!IComplianceModule(modules[i]).check(from, to, amount)) {
            return false;
        }
    }
    return true;
}

Each module is a contract that knows exactly one rule. A JurisdictionModule reads the receiver's OnchainID country claim against an allowed-country bitmap. A LockUpModule reads the receiver's last subscription timestamp against a lock-up window. A MaxHolderModule checks the prospective post-transfer balance against a per-investor cap. Adding a new rule is a matter of deploying a module and registering it, not of upgrading the token.

Revert as a feature, not a bug

The default failure mode is "transfer never happened." When canTransfer returns false, the EVM rolls back state and the sender's balance is unchanged. Gas is consumed; nothing else is. A non-compliant transfer is not a partial transfer, not a quarantined transfer, not a "we'll sort it out tomorrow" transfer. It is a no-op. The sender retains the asset, the receiver gets nothing, the audit trail captures the attempt. This is structurally different from a bank wire sitting in a suspense account at the receiving bank pending compliance review. The on-chain version has no suspense state.

The implication for product design is that front-ends need to pre-flight the check. A naive integration surfaces a revert as a generic "transaction failed," which is unhelpful. A serious integration calls canTransfer as a view function first, gets the rejection reason from the compliance module, and surfaces the actual constraint (jurisdiction blocked, lock-up active, receiver not whitelisted). This is one of the load-bearing parts of the Securitize, Tokeny and Morgan Money front-ends.

The upgrade path that this enables

Compliance changes do not require token upgrades. When CFTC Letter 25-39 was issued in December 2025 covering tokenised MMF shares as cleared-derivatives collateral, every issuer running a tokenised MMF used in that capacity needed updated compliance modules. In an ERC-1400 world the rule lives inside the token contract and the change is a token upgrade. In an ERC-3643 world the change is a new compliance module deployed and registered, with the token untouched. The holder population is undisturbed; balances are unchanged; the audit perimeter is the new module rather than the entire token. That is the architectural reason institutional issuers converged on the standard, and the reason it has held since 2021.

Part 4 covers how the wallets being checked against this rule set are actually constructed (MPC, multi-sig, qualified custody) and which providers institutional clients use. Part 5 covers the operational edge cases (key compromise, forced freeze, beneficial-ownership change) that the architecture has to handle without disrupting normal flows.