Fed Scraps 2023 Crypto Banking Ban That Blocked Crypto Bank Custodia
The Federal Reserve withdrew its 2023 policy statement that effectively barred banks from crypto activities and denied Custodia Bank’s master account application.
The move comes as Wyoming-chartered Custodia pursues a full-court appeal of its master account denial, while regulatory agencies expose widespread debanking practices that systematically excluded crypto firms from traditional banking services between 2020 and 2023.
Vice Chair for Supervision Michelle Bowman said the policy shift creates pathways for responsible innovation while maintaining safety standards.
“New technologies offer efficiencies to banks and improved products and services to bank customers,” she said.
The original 2023 guidance had limited state member banks to activities permitted under other federal banking regulations, but evolving financial systems and improved regulatory understanding rendered those restrictions obsolete.
Custodia Escalates Legal Battle After Years of Regulatory Roadblocks
Custodia filed a petition with the Tenth Circuit Court of Appeals on December 15, requesting en banc review of the Fed’s denial of its master account after a three-judge panel upheld the rejection in October.
The bank argues the decision violates the Monetary Control Act’s mandate that payment services “shall be available” to eligible depository institutions, creating unconstitutional veto power over state banking charters.
Without master account access, Custodia cannot use Federal Reserve wire transfers or automated clearinghouse systems despite meeting all statutory requirements under Wyoming’s Special Purpose Depository Institution framework, which requires 100% reserve backing and prohibits lending to reduce risk.
The petition raises federalism concerns about federal regulators effectively overriding Wyoming’s 2020 charter decision, which was designed to attract digital asset companies within stringent safety parameters.
Back in November, Judge Timothy Tymkovich’s dissent highlighted that granting unreviewable discretion to regional Reserve Bank presidents raises constitutional questions, since those officials are selected by private bank directors rather than appropriately appointed as federal officers.
The dissent created a 2-2 split among circuit judges on whether the Monetary Control Act mandates master account access, with Tymkovich writing that the Fed’s interpretation grants unreviewable discretion while contradicting the statute’s plain language.
The Kansas City Fed denied Custodia’s application in January 2023 after 27 months, citing crypto-asset risks despite internal documents showing staff deemed the bank’s capital adequate and its executive team impressive.
Federal Reserve Governor Christopher Waller has since acknowledged the Fed possesses sufficient tools to manage risks through tailored account structures without resorting to blanket denials.
His October remarks undermined the necessity argument that regulators used to justify rejecting Custodia’s application, while broader investigations revealed systematic exclusionary practices across major banks.
Banking Giants Exposed for Inappropriate Crypto Restrictions
The Office of the Comptroller of the Currency released findings showing all nine largest national banks imposed inappropriate restrictions on lawful businesses, including digital asset companies, between 2020 and 2023.
JPMorgan Chase, Bank of America, Citibank, Wells Fargo, U.S. Bank, Capital One, PNC, TD Bank, and BMO maintained internal policies requiring escalated approvals or blanket restrictions on sectors conflicting with institutional values.
The review examined thousands of debanking complaints after President Trump signed an August executive order intended to prevent account closures based solely on crypto activity.
OCC Comptroller Jonathan Gould said the practices were widespread and represented improper use of national bank charters.
Some users claimed their accounts were abruptly closed under vague references to concerning activity, fueling allegations of coordinated exclusion similar to Operation Chokepoint.
Banks insisted they did not discriminate, but many restrictive policies were publicly visible throughout the investigation period.
The regulatory shift extends beyond debanking investigations.
The OCC conditionally approved five crypto firms, including Circle and Ripple, to launch national trust banks in December, giving digital asset companies access to federal banking charters with single-rulebook oversight instead of navigating state-by-state regulations.
Paxos received federal supervision to issue stablecoins, while Ripple’s charter excludes RLUSD issuance but allows custody and settlement services without deposit-taking or lending activities.
The approved firms have 18 months to raise capital, assemble staff, and build compliant infrastructure before facing final OCC examination.
You May Also Like
The Stunning ASEAN Winner Emerges As Manufacturing Shifts Accelerate
MySQL Single Leader Replication with Node.js and Docker
command: --server-id=1 --log-bin=ON The --server-id option gives each MySQL server in your replication setup its own name tag. Each one has to be unique and without it, replication won’t work at all. Another cool option not included here is binlog_format=ROW. This tells MySQL how to keep track of changes before passing them along to the replicas. By default, MySQL already uses row-based replication, but you can explicitly set it to ROW to be sure or switch it to STATEMENT if you’d rather log the actual SQL statements instead of row-by-row changes. \ Run our containers on docker Now, in the terminal, we can run the following command to spin up our database containers: docker-compose up -d \ Setting Up Our Master (Primary) Server To configure our master server, we would have to first access the running instance on docker using the following command docker exec -it mysql-master bash This command opens an interactive Bash shell inside the running Docker container named mysql-master, allowing us to run commands directly inside that container. \ Now that we’re inside the container, we can access the MySQL server and start running commands. type: mysql -uroot -p This will log you into MySQL as the root user. You’ll be prompted to enter the password you set in your docker-compose.yml file. \ Next, we need to create a special user that our replicas will use to connect to the master server and pull data. Inside the MySQL prompt, run the following commands: \ CREATE USER 'repl_user'@'%' IDENTIFIED BY 'replication_pass'; GRANT REPLICATION SLAVE ON . TO 'repl_user'@'%'; FLUSH PRIVILEGES; Here’s what’s happening: CREATE USER makes a new MySQL user called repl_user with the password replication_pass. GRANT REPLICATION SLAVE gives this user permission to act as a replication client. FLUSH PRIVILEGES tells MySQL to reload the user permissions so they take effect immediately. \ Time to Configure the Replica (Secondary) Servers a. First, let’s access the replica containers the same way we did with the master. Run this command in your terminal for each of the replica containers: \ docker exec -it <replica_container_name> bash mysql -uroot -p <replica_container_name> should be replace with the name of the replica container you are trying to setup b. Now it’s time to tell our replica where to get its data from. While inside the replica’s MySQL shell, run the following command to configure replication using the master’s details: CHANGE REPLICATION SOURCE TO SOURCE_HOST='mysql-master', SOURCE_USER='repl_user', SOURCE_PASSWORD='replication_pass', GET_SOURCE_PUBLIC_KEY=1; With the replication settings in place, let’s fire up the replica and get it syncing with the master. Still inside the MySQL shell on the replica, run: START REPLICA; This starts the replication process. To make sure everything is working, check the replica’s status with:
SHOW REPLICA STATUS\G; Look for Replica_IO_Running and Replica_SQL_Running — if both say Yes, congratulations! 🎉 Your replica is now successfully connected to the master and replicating data in real time.
Testing Our Replication Setup from the Node.js App Now that our replication is successfully set up, we can configure our Node.js server to observe the real-time effect of data being replicated from the master server to the replica server whenever we write to it. We start by installing the following dependencies:
npm i express mysql2 sequelize \ Now create a folder called src in the root directory and add the following files inside that folder connection.js, index.js and model.js. Our current directory should look like this We can now set up our connections to our master and replica server in the connection.js file as shown below
const Sequelize = require("sequelize"); const sequelize = new Sequelize({ dialect: "mysql", replication: { write: { host: "127.0.0.1", username: "root", password: "master", database: "replicaDb", }, read: [ { host: "127.0.0.1", username: "root", password: "slave", database: "replicaDb", port: 3307 }, { host: "127.0.0.1", username: "root", password: "slave", database: "replicaDb", port: 3308 }, { host: "127.0.0.1", username: "root", password: "slave", database: "replicaDb", port: 3309 }, ], }, }); async function connectdb() { try { await sequelize.authenticate(); } catch (error) { console.error("❌ unable to connect to the follower database", error); } } connectdb(); module.exports = { sequelize, }; \ We can now create a User table in the model.js file
const {DataTypes} = require("sequelize"); const { sequelize } = require("./connection"); const User = sequelize.define("User", { name: { type: DataTypes.STRING, allowNull: false, }, email: { type: DataTypes.STRING, unique: true, allowNull: false, }, }); module.exports = User \ and finally in our index.js file we can start our server and listen for connections on port 3000. from the code sample below, all inserts or updates will be routed by sequelize to the master server. while all read queries will be routed to the read replicas.
const express = require("express"); const { sequelize } = require("./connection"); const User = require("./model"); const app = express(); app.use(express.json()); async function main() { await sequelize.sync({ alter: true }); app.get("/", (req, res) => { res.status(200).json({ message: "first step to setting server up", }); }); app.post("/user", async (req, res) => { const { email, name } = req.body; let newUser = await User.build({ name, email, }); // This INSERT will go to the write (master) connection newUser = newUser.save({ returning: false }); res.status(201).json({ message: "User successfully created", }); }); app.get("/user", async (req, res) => { // This SELECT query will go to one of the read replicas const users = await User.findAll(); res.status(200).json(users); }); app.listen(3000, () => { console.log("server has connected"); }); } main(); When you make a POST request to the /users endpoint, take a moment to check both the master and replica servers to observe how data is replicated in real time. Right now, we are relying on Sequelize to automatically route requests, which works for development but isn’t robust enough for a production environment. In particular, if the master node goes down, Sequelize cannot automatically redirect requests to a newly elected leader. In the next part of this series, we’ll explore strategies to handle these challenges
