Before Your Bank Engages With Digital Assets: An Operational Readiness Checklist
The governance framework tells you what to decide. The operational checklist tells you whether you can actually do it. Part 3 of 3.
PART 3 OF 3: DIGITAL ASSET GOVERNANCE FOR COMMUNITY BANKS:
Part 1 covered why community banks need a defined digital asset position now. Part 2 covered the six governance areas every framework must address. This post is the operational layer: what your bank needs to have working before any digital asset activity begins.
TL;DR
Most community banks that encounter problems with digital asset implementation discover the gaps after they have made a commitment, not before. The operational readiness work is not the same as the governance framework from Part 2. Governance defines what the bank is authorized to do and who is responsible. Operations defines whether the bank can actually do it. This checklist covers six areas: integration model selection, reconciliation design, wallet-to-customer mapping, policy and procedure documentation, staff readiness, and board reporting structure. Working through it before making any digital asset commitment tells you what the engagement will actually require and where the gaps are.
Digital assets were named the second most important technology trend for 2026 by community bankers, according to CSI's Industry Outlook, behind only AI. The combination of the GENIUS Act's implementation timeline, live bank-built tokenized deposit infrastructure, and growing examiner attention means that digital asset readiness is no longer a question most community banks can defer. What most banks have not yet worked through is the distance between a governance framework on paper and an operational capability that can actually support digital asset activity safely.
Baker Newman Noyes' analysis of the GENIUS Act's implications for community banks put it directly: a readiness assessment conducted before any product commitment gives the bank a clear picture of what gaps exist and what it will cost to close them. Fair value measurement under ASC 350, on-chain to general ledger reconciliation, key management and wallet security controls, and BSA/AML compliance for blockchain-based transactions are all areas where existing policies and systems may be insufficient.
This checklist works through each of those areas in practical terms. It is structured for the COO, operations lead, or technology officer who has received board authorization to assess readiness and needs to know what that assessment actually covers.
First Step: Form the Working Group
Before any checklist item can be properly assessed, the bank needs a cross-functional team to do the assessing. The Financial Brand's March 2026 analysis of bank digital asset infrastructure readiness noted that the most successful approach is forming a cross-functional working group spanning finance, risk, compliance, IT, and operations, sometimes called a "Digital Asset Working Group", or DAWG.
The working group does not need to be large. At most community banks it is three to five people: the COO or operations lead, the BSA officer or compliance officer, the CFO or controller, and the CIO or IT lead. The group needs executive sponsorship and a clear mandate from the board: assess the bank's operational readiness to support digital asset activity and report findings within a defined timeframe.
Without a named working group and a defined mandate, the checklist below becomes a document that circulates without producing decisions. Assign ownership before beginning the assessment.
Checklist Area 1: Integration Model Selection
The first operational decision is how the bank's existing core and ledger systems will connect to digital asset infrastructure. This is not primarily a technology decision. It is a scope decision that determines how much internal IT involvement is required, what the realistic timeline to live activity is, and what the ongoing maintenance burden will be.
The three integration models for community banks
The Hazel Network white paper describes three models for community banks joining a tokenized deposit consortium. Understanding which model fits the bank's infrastructure determines the staffing, timeline, and technical requirements for everything else on this checklist.
Basic: The bank participates through the Hazel platform and console with compliance screening handled at the network level. No integration on the bank's side is required and no change to the core is needed. Suitable for banks that want to begin participating before internal systems are integrated. Realistic timeline to live activity: four to six weeks.
Advanced: The network delivers scheduled file feeds to the bank, including a posting file with tokenized deposit activity, a compliance file with transaction data, and an online banking widget. The bank ingests these files into its core and compliance systems using existing batch processes. Suitable for banks with a defined integration path that prefer a batch rhythm. Timeline: eight to twelve weeks depending on core configuration.
Enterprise: The bank integrates via API, receiving real-time debits and credits and initiating transactions programmatically. Suitable for banks that want to build programmable products on the settlement layer. Timeline: twelve weeks or longer, with significant internal IT involvement.
Checklist items for this area
The working group has reviewed all three integration models and selected the model that fits the bank's current IT capacity and timeline.
If Advanced or Enterprise, the core provider has been contacted to confirm compatibility and the integration timeline has been scoped.
IT resource requirements have been identified and confirmed available for the selected model.
The integration model selection has been documented and presented to the board as part of the readiness assessment.
Checklist Area 2: Reconciliation Design
On-chain digital asset activity produces settlement records that exist outside the bank's general ledger. Every tokenized deposit transaction, every transfer, every reserve position change produces an on-chain record that has to be reconciled to the bank's books. Getting this reconciliation right before going live is not optional. Getting it wrong after going live produces accounting discrepancies that are visible to auditors and examiners.
What reconciliation design covers
Reconciliation design for digital assets addresses three questions. First, what on-chain events need to map to general ledger entries? Mints, burns, transfers in and out of consortium, reserve position changes, and fee transactions each have accounting treatment that needs to be defined before the first transaction settles. Second, what is the reconciliation cycle? On-chain activity is continuous and 24/7. The bank's existing reconciliation processes run on banking-hours batch cycles. The reconciliation design needs to define how the bank handles on-chain activity that occurs outside its normal processing windows. Third, how are exceptions handled? When the on-chain record and the ledger record do not agree, the investigation and resolution process needs to be defined before it needs to be used.
The Wolters Kluwer analysis of GENIUS Act implementation requirements noted that effective reserve management systems are essential to track assets, reconcile flows, and meet the Act's reporting requirements. For community banks using a consortium like Hazel, the posting files in the Advanced model provide structured data that can feed into existing reconciliation workflows.
Checklist items for this area
The accounting treatment for each digital asset transaction type has been defined: tokenized deposit issuance, transfer in, transfer out, stablecoin conversion at the consortium boundary, fee transactions, and reserve position changes.
ASC 350 fair value measurement requirements for any digital assets held on the bank's balance sheet have been reviewed with the bank's accounting firm or auditor.
The reconciliation cycle has been defined and the finance team has confirmed the workflow can accommodate digital asset activity, including activity that occurs outside standard banking hours.
Exception handling procedures are documented: when the on-chain record and the ledger record disagree, who investigates, what the resolution timeline is, and how the resolution is documented.
The bank's external auditor has been informed that the bank is assessing digital asset readiness and has confirmed their firm's capability to audit digital asset-related financial statements.
Checklist Area 3: Wallet-to-Customer Mapping
In traditional banking, every account is associated with a verified customer identity. In digital assets, the on-chain record of a transaction references a wallet address, not a customer name. The bank needs a maintained mapping between on-chain wallet addresses and the customer accounts they represent. Without this mapping, the bank cannot satisfy customer identification requirements, cannot respond to examiner requests about specific transactions, and cannot produce the audit trail that BSA compliance requires.
What wallet-to-customer mapping requires
For consortium participants, the wallet addresses for each member bank's customers are provisioned by Custodia as the technology provider. The bank maintains the customer-wallet mapping in its own systems, linked to the customer's account record in the core. When tokens are sent to a customer's wallet address, the corresponding customer account is credited. The mapping is the mechanism that makes this work.
The mapping also has to be current. When a customer's account status changes, when a business entity's beneficial ownership changes, or when a wallet address needs to be updated, the bank needs a defined process for updating the mapping and propagating that update to the network's address registry.
Checklist items for this area
The mechanism for maintaining the customer-wallet address mapping has been identified: which system holds the mapping, how it is updated, and who is responsible for its accuracy.
The customer identification program has been reviewed and updated to include wallet address documentation as a required element for any customer with digital asset account access.
The process for updating the mapping when a customer's account status or wallet address changes is documented and has been tested.
The process for communicating wallet address changes to the network's address registry has been confirmed with the network technology provider.
The mapping can be exported and produced in response to an examiner request within minutes, not hours.
Checklist Area 4: Policy and Procedure Documentation
Every operational area on this checklist requires a corresponding written policy or procedure. This is not bureaucratic overhead. It is the documentation that allows a new staff member to execute the process correctly, allows a supervisor to verify that execution, and allows an examiner to confirm that the bank's actual operations match its stated approach. BSA/AML compliance for blockchain-based transactions and key management and wallet security controls are two areas where existing policies and systems may be insufficient. The gap is almost always a documentation gap before it is a process gap.
Minimum policy documentation for digital asset engagement
Digital asset authorization policy: the board-adopted document from Part 2's Area 1, defining permitted activities, prohibited activities, and the approval process for new activities.
Digital asset BSA/AML procedures: an update to the existing BSA program covering wallet address monitoring, on-chain transaction screening, SAR filing for digital asset activity, and record-keeping requirements. This update should be reviewed and approved by the BSA officer before any live activity.
Custody and key management procedures: for consortium participants, this covers the bank's oversight of the custodian's key management arrangements, including the annual review process and the escalation path if custody-related concerns arise.
Reconciliation procedures: the documented workflow for reconciling on-chain activity to the general ledger, including the exception handling process from Checklist Area 2.
Customer onboarding procedures for digital asset accounts: the updated customer identification and due diligence procedures that incorporate wallet address documentation and any digital asset-specific risk factors.
Incident response procedures: what the bank does if a digital asset transaction fails, if a wallet address is frozen or seized by the network, if a compliance alert is generated by on-chain monitoring, or if the network itself experiences an outage.
Checklist items for this area
Each of the six minimum policy documents listed above has been drafted, reviewed by the appropriate functional owner, and approved before live activity begins.
The BSA officer has reviewed and signed off on the digital asset BSA/AML procedures update.
The board has received and acknowledged the authorization policy and the incident response procedures.
A policy review cycle has been established: digital asset policies should be reviewed at least annually or when material changes occur in the network, the regulatory environment, or the bank's digital asset activities.
Checklist Area 5: Staff Readiness
Digital asset operations require staff who understand enough about the technology and the regulatory environment to execute their responsibilities correctly and recognize when something requires escalation. The depth of knowledge required varies significantly by role. Most community bank staff do not need deep technical knowledge of blockchain infrastructure. They need enough operational understanding to do their specific job and enough situational awareness to know when something is outside their expertise.
Role-specific readiness requirements
Board members: sufficient understanding to ask informed questions about digital asset strategy, governance, and risk. This typically requires a two-hour orientation session covering the GENIUS Act basics, the consortium model, and the bank's specific authorization boundaries.
BSA officer and compliance staff: detailed working knowledge of digital asset transaction monitoring, on-chain screening, wallet address documentation, and SAR filing for digital asset activity. Formal training from a recognized BSA/AML training provider with digital asset curriculum is appropriate.
Operations and finance staff: working knowledge of the reconciliation process, the customer-wallet mapping, and the incident response procedures. Process-level training conducted internally using the documented procedures from Checklist Area 4.
IT and technology staff: sufficient technical knowledge to manage the integration model selected in Checklist Area 1, including the API or file feed configuration, the wallet infrastructure interface, and the on-chain monitoring tools.
Customer-facing staff: enough understanding to answer basic customer questions about digital asset account features without overpromising capabilities or making representations about risk. A brief FAQ-based training document is typically sufficient.
Checklist items for this area
Each operational role involved in digital asset activity has been identified and mapped to a specific training requirement.
Training has been completed and documented for each role before live activity begins. Documentation includes who received training, what training was provided, and when.
The BSA officer has completed formal digital asset BSA/AML training from a recognized provider.
A refresher training schedule has been established: digital asset staff training should be updated at least annually and when significant changes occur in the network, the regulatory environment, or the bank's activities.
Checklist Area 6: Board Reporting Structure
The board authorized the digital asset engagement. It now needs a regular reporting structure that gives it the information required to oversee that engagement on an ongoing basis. The reporting structure is not a quarterly presentation with high-level activity summaries. It is a defined set of metrics and exception reports that would allow the board to identify a problem before it becomes an examination finding.
What the board reporting package should include
A board reporting structure for digital asset activity at a community bank typically operates on two cadences: a quarterly dashboard for routine oversight and an immediate escalation protocol for material events.
The quarterly dashboard should cover: total digital asset transaction volume by type (tokenized deposit issuance, transfers in, transfers out), exception and incident count with resolution status, compliance alert summary from on-chain monitoring, reserve attestation review status, and any material changes in the regulatory environment or the network's operating terms since the prior report.
The immediate escalation protocol should define what events require board notification outside the normal reporting cycle: network outages or service disruptions, wallet freezes or seizures, SAR filings related to digital asset activity, regulatory inquiries or examination requests specific to digital assets, and any material changes to the bank's authorization boundaries.
Checklist items for this area
The board reporting template has been drafted and reviewed by the board chair or audit committee chair before live activity begins.
The quarterly reporting cadence has been added to the board meeting calendar.
The immediate escalation protocol has been defined: what events trigger a report, to whom the report goes, and within what timeframe.
The first board report has been scheduled for no more than 90 days after live activity begins.
Operational Readiness Summary Cheat Sheet
A Realistic Timeline
Working through all six checklist areas concurrently, a community bank selecting the Basic integration model can realistically complete operational readiness preparation in eight to twelve weeks from the time the working group is formed and funded. Banks selecting the Advanced model should expect twelve to sixteen weeks. Enterprise model readiness will take longer, and the IT scoping work should be completed before any other readiness work begins.
These timelines assume the governance framework from Part 2 is already in place. A bank that is starting from scratch on both governance and operations should add four to six weeks for the governance documentation work to reach the point where operational readiness assessment makes sense.
The most common mistake is compressing the timeline by running checklist areas sequentially rather than concurrently and by underestimating the time required for policy documentation review and approval. Policy documents that have not been reviewed and approved by the relevant functional owners before live activity begins are not ready policies. They are drafts.
In most community bank digital asset readiness assessments, the gap is not technology. It is documentation. The integration model can often be selected quickly. The reconciliation workflow can be mapped in a few sessions. The wallet-to-customer mapping mechanism is often already partially in place through the core system. What takes the most time, and what is most often incomplete when live activity begins, is the policy and procedure documentation. The BSA/AML update, the customer onboarding procedure revision, and the incident response procedures are the items that require the most cross-functional review and the most time to get right. Start with documentation.
The Role Shore Plays
Reconciliation and ongoing reconciliation management, data lineage and audit trail infrastructure, and vendor oversight documentation are functions where Shore's managed services model delivers the operational capability directly rather than requiring the bank to build it. For community banks working through examination readiness more broadly, the same documentation and data infrastructure that satisfies examiner expectations for traditional banking also satisfies the audit trail requirements for digital asset activity. These are not separate programs, they are the same operational discipline applied to a new asset class.
Frequently Asked Questions
How long does a full digital asset readiness assessment take for a $500M community bank?
For a $500M community bank starting with the Basic integration model and an existing governance framework, a thorough readiness assessment working through all six checklist areas typically takes four to six weeks with a dedicated working group. The most time-consuming elements are policy documentation review and approval (which requires sign-off from multiple functional owners) and BSA officer training (which should be formal training from a recognized provider rather than internal orientation). Banks that try to compress this timeline by deferring documentation until after go-live consistently encounter examination and audit issues that could have been avoided.
Do we need to complete all six checklist areas before the first transaction settles?
Yes, for Checklist Areas 3, 4, and 5. Wallet-to-customer mapping, policy documentation, and staff training need to be in place before any live activity. Checklist Area 1 (integration model selection) is the decision that begins the process, not a completion criterion. Checklist Area 2 (reconciliation design) should be complete before live activity but some elements can be refined through a parallel-run period before going fully live. Checklist Area 6 (board reporting structure) should be defined before go-live but the first actual report occurs after live activity begins.
What happens if our core provider does not have digital asset integration capability?
Most community bank core providers (Fiserv, Jack Henry, FIS, and others) are actively developing or have released digital asset integration capabilities. For banks on cores without current digital asset support, the Basic integration model is the appropriate starting point: it operates through the network's platform and console without requiring core integration. As core providers release digital asset integration capabilities, the bank can migrate from Basic to Advanced without changing its network participation. The integration model decision is not permanent.
What does a board report look like in practice?
At early-stage participation with low transaction volume, the quarterly board report is typically a one-page dashboard with five to seven metrics: transaction volume by type, exception count with status, compliance alert summary, reserve attestation confirmation, and any material regulatory or network changes. As activity grows, the dashboard expands proportionally. The point is not the length of the report. It is that the board is receiving consistent, structured information that would allow a board member to ask an informed question and expect a specific answer.
What if we complete the readiness assessment and decide not to proceed?
The readiness assessment has value regardless of the outcome. A bank that works through all six checklist areas and decides that the operational requirements are not worth pursuing at this time has produced documentation of its governance framework, an updated vendor oversight assessment, current BSA/AML policy documentation, and a board-level record of its digital asset position. All of these have examination value independent of any digital asset activity. The assessment is not wasted if the bank decides not to proceed. It is the governance foundation that examination conversations will draw on whether the bank engages or not.