> ## Content Index
> Fetch the complete content index at: https://www.productftw.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# How to Implement Credit Card Regulatory Changes - ProductFTW #99
- URL: https://www.productftw.com/how-to-implement-credit-card-regulatory-changes/
- Published: 2026-10-01T16:15:06.000Z
- Updated: 2026-10-01T16:15:06.000Z
- Description: Regulatory changes can touch far more than your disclosures.
- Author: Ellen Dearborn
- Tags: Fintech, How To, Product Management

In 2024, I was in the middle of launching a new credit card when the CFPB decided late fees should be $8\. Which, yes, was only two years ago, even though talking about financial regulation in 2024 already feels like telling a story from another lifetime.

At the time, we had a decision to make. The CFPB had finalized the rule, but it hadn’t taken effect yet. It was already being challenged, and there were plenty of questions about what was going to happen. Meanwhile, we were building a credit card that needed a late fee. What were we supposed to build? I remember looking around at what other companies were doing and seeing some of them start changing their late fees before they were required to. Do we change ours too? Do we wait? What happens if we build for $8 and the rule never takes effect?

Spoiler: it didn’t. The CFPB finalized the rule in March 2024, and it would have created an $8 late fee safe harbor for larger card issuers, which it defined as issuers with more than 1 million open credit card accounts. The rule was challenged, never took effect, and was eventually vacated in 2025\. Then, in 2026, the Senate introduced legislation that would put an $8 cap into law. What happens next? Who knows.

This is #8 in the [Consumer Credit is Challenging](https://www.productftw.com/consumer-credit-is-challenging/) series: the rules can change under you after you’ve already built for them. I think there is another lesson here for product managers, though: sometimes the rules haven’t changed yet, and you still have to decide what you’re going to do.

When a regulation is proposed or finalized, there can be this weird period where you know something might change, but you aren’t necessarily required to do anything yet. You can wait until you are forced to make the change, make it early, or decide that you like where the regulation is headed and make the change regardless of what ultimately happens. The thing to remember is that making the change early can also be a signal. Whether you intend it to or not, you may be telling your customers and the market where your company stands on the policy.

My personal product-management rule is that if I am working at a fintech, especially one launching a new product, I probably don’t need to be the company making that statement. If we aren’t one of the major players shaping the market, I would rather understand what is happening, figure out what our obligations are, get ready for the change, and implement it when we need to. There are absolutely reasons a company might choose differently, but generally I don’t think a fintech needs to volunteer to be the test case.

![Infographic showing a credit card late fee changing from $27 to $8 and the resulting updates across compliance, finance, disclosures, customer communications, engineering, statements, testing, and versioning.](https://www.productftw.com/content/images/2026/09/productftw99.jpg)

Just update the fee. Easy.

Once you have to implement the regulation, I follow a pretty standard playbook. First, I get everyone in a room. Product, legal, compliance, engineering, operations, finance, and whatever partner actually controls the affected part of the product all need to understand what is changing.

Finance matters because a regulatory change can completely change the product's economics. If late fees are going from $30 or $40 to $8, what does that do to the model? How much revenue goes away? Does that change the economics enough that we need to rethink something else about the product? I want finance to rerun the model so we understand the business impact of the change, not just the work required to implement it.

Legal and compliance need to interpret the rule. Who does it apply to? When does it take effect? Does it apply to existing customers, new customers, or both? What needs to change in the cardholder agreement? What disclosures need to change? Do we need to notify existing customers? How much notice do we need to give them? It is really easy as a product person to think, “We changed the terms, we’ll just tell the customer,” but credit doesn’t really work like that.

Regulation Z has specific requirements around changes to credit card account terms. Certain significant changes generally require written notice at least 45 days before the change becomes effective, although there are exceptions and not every change is treated the same way. A decrease in a fee, for example, isn’t necessarily treated the same way as an increase. This is why I am not making that determination as the product manager. Legal and compliance are going to tell me what we are required to do, and then I am going to make sure the product can actually do it.

## Sign up for ProductFTW

A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software.

Subscribe 

Email sent! Check your inbox to complete your signup. 

No spam. Unsubscribe anytime.

For something like a late fee, we also need to figure out everywhere that fee exists. It could be in the account-opening disclosures, the cardholder agreement, a change-in-terms notice, the periodic statement, customer support content, and probably a few other places depending on how the product was built. Changing the late fee from one number to another sounds simple until you realize how many places that number lives.

Then someone has to change the fee in the system. If you own your ledger and servicing stack, maybe engineering handles it. If you are a fintech sitting on top of a processor or issuing platform, it might be a configuration your partner has to change. Either way, “change the late fee to $8” is not a requirement I would ever hand to engineering.

I need to know when it changes, which accounts it applies to, what happens to an account whose billing cycle crosses the effective date, what event determines which fee applies, when the customer needs to have received the new terms, what the statement shows, and what happens if the fee gets assessed and then reversed. Then we need to test all of it.

I want to know that the backend charges the correct fee on the correct date and that the statement displays the correct fee. I want to know we aren’t accidentally charging someone under the old terms after the new terms take effect. I also want customer support to know what changed because someone is eventually going to ask why they were charged $8 when they used to be charged something else.

Then there is one of my favorite topics: versioning. We have [talked about document versioning before](https://www.productftw.com/productftw-41-managing-the-legal-files/), and regulatory changes are exactly why I care about it so much. If we change the cardholder agreement or disclosures, I want to know which version every customer received and which version applied to that customer at any point in time.

If someone calls six months later and says, “You charged me the wrong late fee,” I do not want someone opening whatever version of the cardholder agreement happens to be sitting on our website that day and trying to figure out what the customer should have been charged six months ago. I want to know exactly what that customer saw and what terms applied to them on that date. Your disclosure version, effective date, customer communication, statement, and backend configuration all need to tell the same story.

This is the part I think people miss when they talk about regulatory changes. From the outside, the change might look like one sentence that changes one number. Inside the product, that one number can change your economics and touch your legal documents, disclosures, customer communications, statement generation, processor configuration, ledger, support tooling, testing plan, and historical records.

In this case, we spent 2024 preparing for a rule that never took effect. It was vacated in 2025, and now, in 2026, lawmakers are trying to bring the $8 cap back through legislation. Maybe it comes back, maybe it doesn’t, or maybe something entirely different replaces it. You can’t control that part, but you can control whether your product is built to respond when the rules change.

# About ProductFTW

[*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it.