Sep. 19, 2026
Comment Letter to the U.S. Securities and Exchange Commission Re: File No. S7-2026-30 - Transfer Agent Rules Modernization; Request for Comment on DLT-Based Recordkeeping To: rule-comments@sec.gov Subject: Regulatory Condition Hash Binding - A Technical Framework for Integrity, Auditability, and Verifiable Compliance Records in DLT-Based Master Securityholder Files Dear Commissioners and Staff of the Division of Trading and Markets: I respectfully submit this comment in response to the Commission's request for comment concerning the modernization of transfer agent rules, particularly the use of blockchain and distributed ledger technology (DLT) in maintaining master securityholder files. This comment proposes a cryptographic framework, referred to as Regulatory Condition Hash Binding, for linking regulatory compliance conditions to security ownership records and delivery-versus-payment (DvP) transactions. The proposed framework is intended to support the integrity, auditability, and independent verifiability of DLT-based recordkeeping systems while preserving the confidentiality of personal information. I. The Distinction Between Regulatory Verification and Record-Level Binding DLT-based securities infrastructure may incorporate regulatory verification mechanisms, including know-your-customer (KYC) and anti-money laundering (AML) checks, sanctions screening, jurisdictional restrictions, and issuer-specific transfer conditions. For example, smart contracts and token compliance frameworks, including ERC-3643 and identity-related infrastructure such as ONCHAINID, can support identity verification, eligibility checks, and transfer restrictions. However, the enforcement of a regulatory condition and the preservation of verifiable evidence that the condition was satisfied are distinct technical functions. A smart contract may verify a condition at the time of transfer and reject a transaction if the condition is not satisfied. Depending on the implementation, the system may also generate transaction events, logs, or other records. Nevertheless, a transfer restriction alone does not necessarily establish a persistent cryptographic relationship between: The regulatory conditions applicable to a particular security position; The identity and continuity of ownership associated with that position; The specific transfer or settlement transaction; and The evidence supporting the regulatory verification performed at the relevant time. This distinction is particularly relevant when a transfer agent must independently access, review, and verify the integrity of a master securityholder file and its associated records. A recordkeeping framework that cryptographically binds regulatory conditions to ownership records could provide an additional mechanism for establishing the relationship between compliance evidence and the security's recorded ownership history. II. Proposed Framework: Regulatory Condition Hash Binding I propose a cryptographic framework that binds applicable regulatory conditions to the security's ownership-history record through a sequence of cryptographic commitments. The framework consists of three principal components: Condition_Hash: A cryptographic commitment representing the applicable regulatory conditions; CB_n: A combined ownership-record value binding the ownership-history hash, regulatory-condition commitment, and sequence information; DvP_Link_n,m: A combined identifier linking the security-side record to the payment-side record for a specific settlement transaction. A. Regulatory Condition Commitment The regulatory conditions applicable to a security position may include: KYC/AML verification status; Sanctions-screening results or attestations; Jurisdictional transfer restrictions; Issuer consent requirements; Trading-halt status; Other applicable regulatory or contractual transfer conditions. These conditions may be represented through canonicalized data, cryptographic commitments, or authenticated attestations. A conceptual representation is: Condition_Hash_n = H(Condition_1 || Condition_2 || ... || AML/KYC_Commitment || Jurisdiction_Hash) Where: H represents a cryptographic hash function; Condition_i represents an applicable regulatory or contractual condition; AML/KYC_Commitment represents a cryptographic commitment or authenticated reference to relevant verification evidence; Jurisdiction_Hash represents a commitment to the applicable jurisdictional restrictions. The input data must use a defined serialization and ordering method to ensure that independent parties can reproduce the same hash from the same underlying data. Where regulatory conditions are supplied by external systems, their authenticity, effective time, and validity must be established through appropriate authentication mechanisms, such as digital signatures, trusted attestations, or authorized data sources. B. Ownership-Record Binding The regulatory condition commitment is then bound to the ownership-history record: CB_n = H(IdentHash_n || Condition_Hash_n || Sequence_n) Where: IdentHash_n represents the ownership-history hash associated with the relevant security position; Condition_Hash_n represents the applicable regulatory-condition commitment; Sequence_n preserves the ordering of the record within the ownership-history chain. This structure establishes a cryptographic relationship between the ownership record and the regulatory conditions associated with that record. If an underlying committed value is changed, the resulting hash will differ when recalculated using the same cryptographic algorithm and serialization rules. The resulting CB_n therefore provides a mechanism for detecting inconsistencies between the recorded ownership state and its associated regulatory-condition commitment. C. Linking the Security Record to the Payment Record For a DvP transaction, the security-side record may be linked to the corresponding payment-side record through a combined identifier: DvP_Link_n,m = H(CB_n || PayHash_m || settlement_id) Where: CB_n represents the security-side ownership and regulatory-condition commitment; PayHash_m represents the relevant payment-side record or payment commitment; settlement_id identifies the associated settlement transaction. The DvP_Link binds the identified security-side state and payment-side record into a single cryptographic reference. The combined identifier can be used to support reconciliation, audit verification, and consistency checks between the security and payment records. D. Verification at the Time of Execution At the time of a proposed transfer or settlement, the system can verify the relevant regulatory conditions and recalculate the associated cryptographic commitments. The verification process may include: Retrieving the applicable ownership record and its sequence information; Obtaining the current regulatory-condition data or authenticated attestations; Recalculating Condition_Hash_n and CB_n; Verifying the relevant payment-side record; Recalculating DvP_Link_n,m; Comparing the calculated values with the expected values associated with the transaction. Where the applicable regulatory conditions have changed, the system can require a new commitment or updated authorization before proceeding. Where the verification results do not satisfy the transaction's required conditions, the smart contract or settlement-control mechanism can reject or prevent execution. The effectiveness of this mechanism depends on the implementation, including the reliability of external attestations, the handling of revoked or expired conditions, and the enforcement of the verification results by the transaction-execution system. The framework therefore provides a method for binding regulatory-condition evidence to ownership and settlement records, rather than relying solely on an isolated eligibility check. III. Potential Contributions to the Commission's Recordkeeping Objectives The proposed framework may support several objectives relevant to DLT-based master securityholder files. A. Integrity By binding Condition_Hash_n to CB_n, and CB_n to the ownership-history chain represented by IdentHash_n, the framework creates a cryptographic relationship between regulatory-condition commitments and ownership records. Changes to committed data can be detected through recalculation and comparison of the corresponding hashes. Where the records are maintained in an appropriately secured and append-only ledger, this structure can support the detection of unauthorized alteration and inconsistencies in the recorded history. The framework does not, by itself, establish that the original data were accurate or that an external compliance determination was correct. Those matters require appropriate validation, authentication, and governance procedures. B. Accessibility and Independent Verification Where the relevant commitments and records are maintained on a DLT accessible to the transfer agent, the transfer agent can retrieve the recorded values and independently recalculate the corresponding hashes. This may reduce dependence on a single third-party system for verifying the integrity of the recorded ownership and regulatory-condition commitments. The framework can also support standardized verification procedures across participating institutions. However, access to a hash alone does not necessarily provide access to the underlying evidence required to interpret or validate the regulatory determination. Accordingly, the system should provide appropriate access to supporting records, verification keys, schemas, and authenticated attestations, subject to applicable privacy and confidentiality requirements. C. Immutability and Auditability A hash-linked record structure can make unauthorized changes to previously recorded data detectable. Where each successive record incorporates the preceding record's cryptographic value, alteration of an intermediate record will cause a mismatch in subsequent hash calculations. This property can support auditability and tamper detection. However, cryptographic hash chaining alone does not necessarily prevent deletion, rewriting, or replacement of records by an administrator or a party controlling the underlying infrastructure. Accordingly, the framework should be implemented with appropriate controls, such as append-only recordkeeping, access restrictions, independent validation, reliable retention procedures, and mechanisms for detecting unauthorized changes. Whether a particular implementation satisfies applicable record-retention and non-rewriteability requirements, including requirements under Rule 17a-4 where applicable, must be determined based on the complete system design and the relevant regulatory provisions. D. Multi-Jurisdictional Compliance The proposed framework can accommodate regulatory conditions originating from multiple jurisdictions. Different conditions may be represented as separate commitments and combined into a common regulatory-condition hash. This enables a system to associate multiple jurisdictional requirements with a specific ownership record and settlement transaction. Where the transaction requires all applicable conditions to be satisfied, the execution mechanism can require verification of the relevant commitments and authenticated attestations before permitting the transfer. The framework may therefore support cross-border settlement processes in which regulatory conditions differ among participating jurisdictions. Its effectiveness would depend on accurate identification of the applicable legal requirements, reliable sources of regulatory information, and appropriate handling of changes in legal or regulatory status. E. Privacy and Confidentiality The framework is designed to permit the recording of cryptographic commitments rather than plaintext personal information. Personal information and sensitive compliance documentation may remain in appropriately protected off-chain systems, while the DLT records the relevant commitments, references, and verification information. This approach may reduce the amount of personal information directly exposed on a public or shared ledger. Nevertheless, a hash should not automatically be treated as anonymous or non-identifiable. Predictable inputs, insufficiently protected identifiers, and publicly available auxiliary information may create re-identification risks. Accordingly, the implementation should use appropriate cryptographic protections, including suitable commitments, salts or other protections against guessing attacks, access controls, and privacy-preserving verification methods where necessary. IV. Relationship to Transfer Agent Recordkeeping The proposed framework is intended to support, rather than replace, the transfer agent's legal responsibilities. A transfer agent using DLT-based recordkeeping would continue to require appropriate procedures for: Maintaining accurate and complete securityholder records; Establishing the authoritative ownership state; Managing corrections, reversals, and legally required updates; Preserving records for the applicable retention period; Providing authorized access to records and supporting evidence; Demonstrating compliance with applicable regulatory requirements. Regulatory Condition Hash Binding could serve as a supplementary technical layer connecting regulatory-condition evidence to ownership and settlement records. Where implemented with appropriate access, retention, authentication, and governance controls, it may help transfer agents demonstrate the integrity and consistency of relevant records without requiring every verification process to be reconstructed manually from separate systems. The framework does not assume that a hash commitment alone constitutes a complete master securityholder file or satisfies every applicable recordkeeping obligation. V. Recommendation I respectfully recommend that the Commission consider cryptographic binding of regulatory-condition commitments to ownership records as a potential technical approach for DLT-based master securityholder files. In particular, the Commission may wish to consider whether recordkeeping frameworks should support the following capabilities: Record-level compliance binding: The ability to associate regulatory-condition commitments with specific ownership records, rather than relying exclusively on transaction-level eligibility checks. Independent integrity verification: The ability of authorized transfer agents and examiners to recalculate and verify cryptographic commitments using accessible records and authenticated supporting evidence. Ownership-history continuity: The ability to link regulatory-condition commitments to an ordered ownership-history record and detect inconsistencies in that record. Settlement linkage: The ability to cryptographically associate security-side records with corresponding payment-side records through a transaction-specific settlement identifier. Privacy-preserving recordkeeping: The ability to maintain verifiable commitments while limiting the disclosure of plaintext personal information on the ledger. Interoperability: The ability to apply consistent verification procedures across different DLT platforms, transfer agents, and jurisdictional compliance systems. These capabilities could provide a technical foundation for improving the verifiability and auditability of DLT-based securities recordkeeping while preserving the transfer agent's responsibility for maintaining the authoritative master securityholder file. I further recommend that the Commission consider whether technical standards or interpretive guidance could clarify the role of cryptographic commitments, authenticated attestations, and hash-linked records in demonstrating record integrity and supporting independent examination. Such guidance could help distinguish between the mere execution of a compliance check and the preservation of verifiable evidence linking that check to the relevant ownership record and settlement transaction. VI. Conclusion Regulatory compliance in DLT-based securities infrastructure involves more than determining whether a transfer is permitted at a particular moment. It also involves maintaining reliable records that establish what ownership state was recorded, which regulatory conditions were associated with that state, and how the relevant transaction was linked to its settlement record. The proposed Regulatory Condition Hash Binding framework provides a cryptographic method for establishing these relationships through Condition_Hash_n, CB_n, and DvP_Link_n,m. When combined with reliable data authentication, appropriate record-retention controls, and enforceable transaction-validation procedures, this approach may support the Commission's objectives concerning the integrity, accessibility, auditability, and reliability of DLT-based master securityholder files. I appreciate the opportunity to submit these comments and would welcome the opportunity to provide additional technical information concerning the proposed framework. Respectfully submitted, seong ho Lee