I did not start my career thinking deeply about regulation. Like most tech-focused product managers, I cared about velocity, user experience, system reliability and scale. That instinct served me well—until I began leading platforms that moved money, made credit decisions and carried long-term financial consequences for customers. Regulation did not show up as paperwork, it showed up as questions the system would eventually be forced to answer. Regulation Is Delayed Interrogation I learned quickly that in banking, regulation is not something that happens at launch. It happens months or years later, often under pressure. Regulators do not ask how a system behaved yesterday; they ask how it behaved in the past, under conditions that no longer exist. While modernizing the Discover Student Loans digital origination platform, every real-time identity check and credit decision created a future obligation. The ability to explain why a specific outcome occurred at a specific moment in time was a primary requirement. I Do Not Interpret Regulation—I Design for It I am not a compliance officer and I never tried to become one. My responsibility was different. I owned systems that had to behave consistently, transparently and defensibly. That meant treating auditability, traceability and explainability as core product requirements. When those qualities were built into the platform, compliance reviews stopped being adversarial and started becoming confirmatory. Auditability Means Narrative Continuity Early on, I learned that logs were not enough. Auditability requires the system to tell a coherent story on its own. On the student loan platform, every application produced an immutable narrative—inputs, model versions, identity checks and timestamps. When questions arose, the system answered them without human reconstruction. That capability removed fear from both regulators and operators. Data Lineage Quietly Determines Speed Some of the largest conversion gains, over $100M annually, came not from flashy features but from clarity. Clear data lineage eliminated disputes, accelerated decisions and reduced operational drag. Once teams trusted the data, they moved faster. Lineage was not a data team concern, it was a product accelerator disguised as governance. Decisioning Systems Demand Explainability Real-time credit decisioning and identity verification sat at the heart of the platform. I treated explainability as an interface contract, not a reporting feature. Decisions had to behave consistently across retries, failures, and degraded states. That discipline allowed the platform to support over $1.2B in private student loan originations without accumulating invisible risk. Automation Raises the Bar As we replaced manual checks with event-driven automation, controls had to scale with the system. Thresholds became code. Exceptions became observable states. Overrides became auditable actions. Automation did not reduce regulatory attention, it increased expectations. Designing for that reality was essential to scaling safely. Incidents Reveal Product Truth Incidents taught me more about product design than any roadmap review. During failures, regulators and executives cared about behavior, not intent. Because we pre-designed kill switches, fallback paths, and honest customer messaging, incident response became calm and defensible rather than chaotic and risky. Regulatory Time Is Real Time I learned to plan roadmaps around regulatory calendars just as deliberately as engineering capacity. Model validations, audits, and policy cycles shaped delivery. Aligning with that reality prevented last-minute freezes and allowed modernization to progress steadily. The Mindset Shift That Changed Everything The most important shift for me was simple: I began designing systems that would still make sense when I was no longer in the room. Regulators read systems like historians, they assume context is gone and evidence is all that remains. Products built with that assumption endure. Closing Reflection Designing for regulation did not slow innovation in my work at Discover and Capital One. It made innovation durable. By treating regulation as a design constraint rather than a blocker, we built platforms that scaled, converted, survived scrutiny and earned trust. For tech PMs entering banking, my advice is simple: regulation is not bureaucracy. It is physics. Design for it early, and your products will last.

Designing for Regulation: A Fintech PM's Perspective

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

AGI 2029: Walking the Fine Line Between Utopia and Existential Risks

AI Restrictions Reinforce Abusive User Behavior

Artificial Intelligence Act (AIA): Europe’s Startups to Restore AI Excellence and Trust?

As we Learn to Use AI, It is Learning to Use Us

Microsoft CEO and Chief Economist Disagree on Regulation Timing for New Technologies - WEF Davos

Balancing AI Innovation & Regulation: Perspectives on Foundation Models and Responsible Development

AGI 2029: Walking the Fine Line Between Utopia and Existential Risks

AI Restrictions Reinforce Abusive User Behavior

Artificial Intelligence Act (AIA): Europe’s Startups to Restore AI Excellence and Trust?

As we Learn to Use AI, It is Learning to Use Us

Microsoft CEO and Chief Economist Disagree on Regulation Timing for New Technologies - WEF Davos

Balancing AI Innovation & Regulation: Perspectives on Foundation Models and Responsible Development

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps