Can a Blockchain Be Your Recordkeeping System? What the CFTC's New FAQs Say

Can a Blockchain Be Your Recordkeeping System? What the CFTC's New FAQs Say

Can a blockchain satisfy a regulated firm's recordkeeping duties? In its September 24, 2026 FAQ update, CFTC staff said blockchain and distributed-ledger records can be used for certain obligations under Regulations 1.31 and 45.2, provided the entity still meets the rules that apply to it. The answer is not a blanket exemption: public, permissionless networks call for contingency controls that can preserve and produce records when the chain or its block explorer is unavailable.

The important distinction is between the medium and the obligation. A ledger can be the medium, but the regulated firm remains responsible for whether a record is authentic, reliable, retrievable, and available for inspection. That distinction is useful well beyond derivatives markets, because builders often confuse a record's persistence with an organization's ability to produce it when asked.

What the CFTC added, and what it did not

On September 24, three divisions of the Commodity Futures Trading Commission released an updated FAQ covering registrants and registered-entity activities involving crypto assets and blockchain technology. The update added four questions, numbered Q12 through Q15. Q12 concerns customer funds invested in tokenized forms of otherwise permitted investments; Q13, Q14, and Q15 address blockchain recordkeeping. The agency's announcement describes the update and its scope here: https://www.cftc.gov/PressRoom/PressReleases/9303-26

That small set of questions does meaningful work. Q13 discusses recordkeeping under Commission Regulation 1.31. Q14 addresses swap-data recordkeeping under Regulation 45.2. Q15 asks whether covered entities must also maintain offchain copies.

The answer is carefully framed around the divisions' willingness not to object in specified situations, not a new permission to disregard the underlying rules. The full text is here: https://www.cftc.gov/media/14671/FAQ_CryptoAsset092426/download

The FAQ also says what it is not. Its answers represent the views of the CFTC divisions that prepared them, do not create new binding rules, do not amend existing rules, and do not necessarily represent the views of the Commission or other offices. That limitation belongs near the top of any summary, not buried in a footnote. It tells readers to treat the document as staff guidance about applying existing requirements, not as a substitute for the requirements themselves. https://www.cftc.gov/media/14671/FAQ_CryptoAsset092426/download

Chairman Michael S. Selig welcomed the update as consistent with the agency's ongoing effort to provide regulatory clarity for the crypto industry. That is a statement of intent, not a claim that every implementation question has been settled. The announcement and the Chairman's exact words are at https://www.cftc.gov/PressRoom/PressReleases/9303-26

For teams tracking the broader policy conversation, this is a different question from how an asset is classified or how a product is promoted. The SEC Division of Corporation Finance's separate crypto FAQs, updated September 28, cover classification, staking receipts, promotional statements, and other securities-law topics, and expressly say they are staff views with no legal force or effect: https://www.sec.gov/about/divisions-offices/division-corporation-finance/faqs-crypto-assets

For builders, the takeaway is practical: read each agency document within its own perimeter. The CFTC update concerns particular Commodity Exchange Act and Commission recordkeeping requirements for covered entities. It does not answer every question about securities rules, privacy obligations, evidentiary standards, or another regulator's retention framework.

A ledger can hold the record, but controls still do the work

Q13 asks whether a records entity can use blockchain or distributed-ledger technology to meet Regulation 1.31. The CFTC divisions say they would not object to creating and maintaining onchain records for that purpose, so long as the entity can fully satisfy Regulation 1.31. The FAQ highlights systems and controls that ensure the authenticity and reliability of electronic regulatory records. See the full response in the CFTC FAQ: https://www.cftc.gov/media/14671/FAQ_CryptoAsset092426/download

That is a technology-neutral answer, not a claim that every chain is suitable for every record. The recordkeeping obligation does not disappear when data is written to a ledger. A team still needs to determine what constitutes the record, how it is tied to the relevant customer or transaction, how corrections and supplements are represented, and how an examiner can receive it in a usable form.

Immutability can help with one part of that task: showing that an entry was not silently rewritten after the fact. But an immutable hash does not automatically show that the source data was accurate when submitted. Nor does it prove that an address was mapped to the correct account, that a correction was handled properly, or that the record can be found without specialized tooling. Those questions belong in the control design, not in the marketing copy.

A useful systems diagram therefore has more than a blockchain box. It includes the source system, the process that validates and formats each record, the signing or authorization step, the ledger transaction, the index used for retrieval, the retention environment, and the process for producing records to an examiner. If one link in that chain fails, a durable block may still be operationally useless.

This distinction connects to the broader issue of programmable compliance. A team can automate checks, preserve evidence, and route exceptions, but the automation needs a documented purpose and accountable owner. Autheo readers can compare that framing with the programmable compliance layer discussion and the CFTC no-action path for software developers, while keeping each article's legal context separate.

Before choosing a network, write down who has to keep the record, which fields must be preserved, how long retention lasts, who can retrieve the data, what format works, and how changes are tracked. These basic answers help teams see whether a ledger solves a need or simply adds another layer.

Q14 makes the same point for swap data

Q14 addresses specified entities using blockchain technology for swap-data records under Regulation 45.2. The divisions say they would not object when the covered entity uses the technology to create and maintain onchain records and can fully satisfy the applicable requirements. The FAQ names swap execution facilities, designated contract markets, derivatives clearing organizations, swap dealers, major swap participants, and certain counterparties. It is not a universal statement for every company that writes data to a chain. https://www.cftc.gov/media/14671/FAQ_CryptoAsset092426/download

The specific regulated activity matters. A recordkeeping pattern that fits one entity's obligations may be insufficient for another entity subject to a different rule, reporting process, or retention period. Teams should map the actors in a workflow before treating a code library or infrastructure configuration as a compliance solution.

The CFTC divisions also tell covered entities to consider their risk-management framework and any implications for existing policies and procedures. That is an invitation to connect technical architecture with internal governance processes, not to leave the architecture discussion to engineers alone. Legal, operations, security, records management, and product owners each see a different failure mode.

For example, a smart contract may emit the correct event, but the event might omit a required field. A data indexer may translate that event into a report, but a software update could change how an old event is decoded. A provider may keep an archive node, yet not have a tested way to export a complete, readable record set. The organization needs end-to-end evidence, not a single successful transaction hash.

Teams building record-producing applications can use a disciplined release process: define the record schema, version it, test emitted data against expected cases, record who approved each change, retain the mapping between events and business records, and periodically test a full export. The smart contract audit checklist and security best practices for smart contracts offer adjacent engineering practices, though neither replaces a legal analysis of a particular recordkeeping obligation.

The update also describes the recordkeeping rules as technology neutral. That principle matters because it keeps the focus on whether a system meets the obligation, not whether the records sit in a conventional database or on a distributed ledger. Technology neutrality does not mean that technical details are irrelevant; it means the implementation must be judged against the requirements that actually apply. https://www.cftc.gov/media/14671/FAQ_CryptoAsset092426/download

No offchain copy is not the same as no recovery plan

Q15 is likely to attract the most attention because the divisions say they would not object solely because a covered entity elects not to keep offchain versions of records. Read every qualifier. The response is limited to the absence of an offchain copy by itself. It does not say backups are forbidden, that recovery planning is unnecessary, or that an inaccessible record is acceptable. https://www.cftc.gov/media/14671/FAQ_CryptoAsset092426/download

The FAQ draws an explicit distinction between public, permissionless networks and private or permissioned networks. For a public and permissionless network, an entity should establish systems and controls that let it retain and produce records during an emergency or disruption, including when the network or its associated block explorer is inaccessible. It should be able to make the records available for Commission inspection even when the usual public interface cannot be reached. https://www.cftc.gov/media/14671/FAQ_CryptoAsset092426/download

That scenario changes the design question. Instead of asking only, 'Is this transaction onchain?', ask, 'Can the organization reconstruct and deliver the required record if the preferred explorer, gateway, or network endpoint is down?' A public explorer is often a convenient window onto chain data. It should not be confused with the record itself, and it should not be the only retrieval path for an entity with regulatory duties.

A resilience plan can include independently maintained copies of the relevant data, documented export procedures, validated parsing tools, access controls, and a test that simulates a provider outage. It should also describe who can invoke the fallback, how integrity is checked, and how the team prevents duplicate or incomplete submissions after service returns. These are design prompts, not a checklist mandated word-for-word by the FAQ.

This principle is familiar in other parts of crypto operations: operational availability, key custody, and incident response are different controls. A record may be correct but temporarily unreachable. A record may be reachable but lack trustworthy provenance. A production system needs to account for both.

The published developer security analysis and crypto infrastructure trust-boundary analysis provide useful companion reading on reducing that gap.

The distinction also prevents a common architecture mistake: making a third-party indexer the only source of truth for a regulated workflow. A service provider can be part of the stack, but the organization should understand what the provider stores, how data is exported, what happens when the service changes, and how records can be verified independently. Vendor documentation is not the same thing as an organization's tested recovery procedure.

A practical review for product and compliance teams

Start with the rule, then test the proposed system against it. Identify the entity with the retention duty and the exact records in scope. Separate the data that must be preserved from data that is merely helpful for analytics. Then define the retrieval format and the people who may need access, including during an emergency.

Next, trace a sample record from its origin to its final export. Capture the source event, any transformations, the onchain transaction, the index or archive used for search, and the file or report delivered to the reviewer. Ask someone who did not build the flow to reproduce the result. If the answer depends on an undocumented command, private account, or single vendor dashboard, the process is not yet robust.

Then test failure conditions in a nonproduction environment. Disable the primary explorer and remove access to the normal indexer, then restore a backup in a separate workspace and compare it with a known-good record. If data cannot be retrieved or its transformation cannot be explained, the architecture has a gap, whether or not the chain remained online.

The strongest documentation connects responsibilities to evidence. For each control, record its owner, frequency, expected output, failure path, and the location of the evidence. Keep the document current when the contract, event schema, indexing provider, or retention process changes. A diagram that no longer matches the deployed system is not an effective control.

Finally, preserve the difference between technical capability and regulatory conclusion. An application may be able to write durable data to a blockchain. That fact alone does not establish that a particular firm's records satisfy a particular rule. The CFTC staff answers explain one set of conditions for covered entities; counsel and compliance teams still need to assess how those conditions interact with the entity's obligations. The SEC's separate September FAQ page is another example of guidance that must be read within its own subject and authority: https://www.sec.gov/about/divisions-offices/division-corporation-finance/faqs-crypto-assets

For teams developing products, this is a useful moment to review release notes, user-facing claims, and support procedures together. Avoid promises that imply a system can meet an obligation simply because it uses a blockchain. State which records are preserved, how retrieval is supported, what is still being built, and what an operator must configure. Clear boundaries help customers evaluate the product without mistaking an architectural feature for a legal conclusion.

Autheo's own platform framing also separates the blockchain trust layer from the infrastructure that executes applications. Staking and transaction fees are live today; compute, storage, and AI inference are rolling out over the coming months. That distinction between an operating capability and a planned layer is the same discipline teams should use in recordkeeping discussions. For the broader architecture, see the complete guide to Autheo and the wider Web3 infrastructure opportunity.

Autheo's goal is to make independently owned resources behave like one logical cloud, with cryptographic trust where it adds value. That architecture does not remove the need to design for evidence, retrieval, and operational accountability. Builders interested in the platform can deploy a first smart contract on Autheo and explore the developer resources at https://www.autheo.com.

Key Takeaways

CFTC staff's September 24, 2026 update added four questions, Q12 through Q15, to its crypto asset and blockchain FAQ.

Q13 and Q14 describe staff non-objection positions for specified recordkeeping duties under Regulations 1.31 and 45.2, subject to full compliance with applicable requirements.

The divisions emphasize authenticity, reliability, risk management, and policies and procedures. A blockchain does not make those controls automatic.

Q15 says staff would not object solely because an entity does not keep offchain copies. For a public, permissionless network, the entity should still be able to retain and produce records during a network, explorer, or other disruption.

These FAQs represent staff views, do not create new binding rules, and do not amend existing regulations. They are not a blanket compliance safe harbor.

Clear recordkeeping starts with clear architecture and tested recovery. If you are building the next generation of distributed infrastructure, learn how Autheo approaches the trust layer, mesh, and developer platform at https://www.autheo.com.