One Shared Stack, One Loophole: Vishak Shetty on the Hidden Risks of Cross-Product Banking Systems

Shared technology stacks function like a master key across a hotel. Efficient for operations. Risky when access extends beyond intended boundaries. In modern banking systems, that same efficiency can expose vulnerabilities that remain invisible until financial loss occurs. According to a McKinsey report on digital banking fraud, cross-product authentication gaps account for nearly 30% of undetected account takeovers at large financial institutions. Separately, the Federal Trade Commission reported that consumers lost over $10 billion to fraud in 2023, underscoring how systemic vulnerabilities continue to translate into real financial damage.

Despite years of API-led integration and platform consolidation, many financial institutions continue to operate with fragmented authentication logic across products built on shared infrastructure. Student Loans. Credit Cards. Deposits. Each product is optimized independently. Fraud, however, does not operate within those boundaries. It exploits the connections between them.

Vishak Shetty, a Senior Manager within the Discover Card Portfolio at Discover and recipient of the Discover President’s Award, has worked directly at that intersection. He identified a cross-product authentication gap that allowed fraudsters to move from Student Loans to Deposits without triggering a single alert. He led the investigation, designed the solution, and executed the fix end to end, stopping an active fraud vector that was draining customer accounts in real time.

We spoke with him about how shared infrastructure creates hidden exposure, why product leaders must think beyond individual systems, and what it takes to close vulnerabilities that standard security models fail to detect.

Vishak, what initially led you to investigate this vulnerability, and what made it stand out from typical fraud signals?

Customers were reporting something that did not align with known fraud patterns. Funds were disappearing from Deposits accounts, yet there was no evidence of forced entry, compromised passwords, or brute-force activity. It appeared as legitimate access.

That inconsistency pointed to a deeper issue. When fraud does not resemble fraud, the problem is often structural. I shifted focus from entry points to the connections between systems.

Student Loans and Deposits shared a profile management layer. Changes made in one product propagated automatically to the other. That design simplified customer management, but it also created an unmonitored pathway.

Fraudsters accessed the Student Loans registration flow, which allowed email-based out-of-band verification, then updated the phone number on the customer profile. That change carried into Deposits. From there, they requested a one-time passcode, received it on their own device, and gained full account access.

The system behaved exactly as intended. That was the issue. Nothing failed. No alerts triggered. The vulnerability existed in how two systems interacted, not within either system individually.

How exactly did the interaction between Student Loans and Deposits create an unmonitored pathway for fraud, and why did existing controls fail to detect it?

Most fraud detection frameworks are built around the assumption that products operate independently. In reality, large financial platforms are deeply interconnected. Shared infrastructure reduces cost and complexity, but it also introduces dependencies that are rarely audited from a security perspective.
According to the Accenture Banking Trends 2026 report, banking systems are increasingly built around continuous, cross-channel interactions, making it harder to isolate risk within a single product and reinforcing the need for system-level fraud detection.

In this case, the difference in authentication rules created the exposure. Student Loans allowed email-based verification to accommodate users who could not reliably receive SMS. Deposits required SMS authentication. That mismatch created a bridge between systems. Fraudsters did not need to break anything. They used the system exactly as designed.

What made it particularly difficult to detect was the absence of noise. There were no anomalies at the individual system level. The risk existed in the transition between them. Security models tend to focus on boundaries. Fraud operates across them.

What made this class of cross-product vulnerability structurally different from conventional fraud vectors that security teams are used to handling?

The difference is where the vulnerability lives. Traditional fraud exists within a system: compromised credentials, phishing, and malware. These are events that trigger alerts because they deviate from expected behavior.

Cross-product vulnerabilities behave differently. They sit in the alignment between systems. Each component operates correctly. The failure emerges only when those components interact under conditions that were never explicitly tested.

Industry research supports this shift. According to a report by IBM on the cost of data breaches, organizations with highly complex system integrations face significantly higher breach costs and longer detection times compared to those with more isolated architectures. Complexity, not just exposure, is becoming the defining risk factor. This is primarily why these vulnerabilities persist. They are not visible in isolation. They require system-level thinking to detect.

When you identified the issue, how did you approach designing a fix that balanced security enforcement with real-world user constraints, especially for international customers?

The technical fix appeared straightforward. Removing email-based verification from the Student Loans registration flow would eliminate the entry point. The challenge was that this would have excluded legitimate users, particularly international customers who depend on email verification due to SMS limitations.

We needed a solution that addressed both security and accessibility. The approach we implemented introduced a bifurcated authentication model. For U.S. customers, registration required mobile-based verification. For international users, both email and mobile options were preserved.

This required a detailed impact analysis across all dependent systems. Any change to the shared profile layer affects multiple products. We evaluated downstream dependencies, aligned with risk and compliance teams, and ensured the solution would not introduce new failure points.

I led the full lifecycle of the solution, from investigation and design to execution, validation, and rollout. The objective was not only to close the vulnerability, but to do so without creating friction for legitimate users.

You work on Pay with Rewards with PayPal operated on the same principle of shared infrastructure. What did that experience teach you about designing systems that scale across products without introducing unintended risk?

That project reinforced the same principle from a different angle. When systems are interconnected, every new capability introduces both opportunity and complexity.

Pay with Rewards enabled cardmembers to redeem rewards directly within the PayPal wallet. That required building new settlement processes capable of handling daily reward redemptions and returns, which did not previously exist at scale. It also required designing a disputes framework for a transaction type with no precedent. The complexity extended beyond engineering. We had to align legal, compliance, and operational teams across two organizations while maintaining a seamless customer experience. Automatic enrollment was a key requirement, which meant securing approval to enroll users without additional steps at the point of card linkage.

Between 2019 and 2025, the initiative drove $356 million in reward redemptions across 12.4 million transactions, with approximately 3.5 million active users. Customers using the feature generated a measurable increase in card usage.

The lesson is consistent. When systems scale across products, success depends on understanding not just what each component does, but how they interact under real-world conditions.

From a systems perspective, how should product leaders rethink fraud prevention and proactively identify cross-product vulnerabilities in shared architectures?

Fraud prevention can no longer be treated as a product-level responsibility. In shared architectures, risk emerges from how systems interact, not just how they are individually secured. Most organizations validate authentication flows within a single product, but rarely examine how identity data propagates across connected systems. That is where vulnerabilities take shape.

The starting point is to audit the handshake between systems, not just at login, but across the full lifecycle of identity changes. Register through a lower-security pathway, modify profile attributes, and observe how those changes propagate. If those changes surface in a higher-value product without additional validation, the vulnerability is structural, not technical.

This does not require new tools. It requires a shift in how product leaders think about system behavior. The teams closest to production systems are best positioned to trace these interactions and identify where assumptions break. In practice, most gaps persist not because they are difficult to fix, but because they are never explicitly tested. The vulnerability we identified has been closed, but similar gaps likely exist elsewhere. The difference will come down to whether they are found deliberately, or discovered through loss.

The work of closing systemic vulnerabilities rarely receives visibility. It does not generate announcements or recognition at scale. Yet its impact is measured in what does not happen, accounts not compromised, funds not lost, trust not broken. As financial systems become more interconnected, the ability to understand and secure the interactions between products will define the next standard of product leadership.