Introduction to Spark executor tuning

Working with Spark is intimidating for new users. Distributed computing concepts to understand, parameters to tune and environments to configure, on top of writing the application code itself! It’s easy to use surface-level Spark knowledge to create an application that works, but developing efficient applications and achieving real performance improvements require a deeper dive into the details of Spark. One such case is Spark executor tuning.

Spark drivers, workers and executors

Spark is an open source unified analytics engine for distributed processing of large volumes of data. Computations are split out over a series of clusters, enabling parallel processing and in turn speeding up execution. Each Spark application runs on a driver node and a series of worker nodes.

The role of the driver in Spark applications

The driver is the “brain,” running the main method of the application. The driver is responsible for building execution plans and orchestrating the computational tasks performed. It analyzes, schedules and sends tasks to worker nodes.

The role of worker nodes in Spark clusters

In contrast, the workers are the “brawn.” Each worker carries out computation tasks and returns the results to the driver.

The role of executors in Spark jobs

Spark jobs are broken down into a series of stages, each composed of tasks that run in parallel on worker node executors. A task is the smallest unit of work in a Spark application. A Spark executor is a process that runs on a worker node in a cluster and executes tasks assigned to it by the driver. Executors perform the actual data computations of a Spark application.

Each executor is allocated a certain amount of memory and CPU cores for storing data and performing computation tasks. By default, Spark creates a single executor for each worker node in a cluster, but users can change the number of executors and the memory and CPU allocated to each executor. This can often lead to improved performance depending on the application.

Details for executors can be configured by using the following Spark parameters when setting up an application: -num-executors, -executor-cores, -executor-memory.

Fat vs. thin vs. optimal executors in Spark

Executors in Spark can be configured in different ways-fat, thin or optimally sized-each with trade-offs in performance, cost and fault tolerance.

Fat executors in Spark

Since Spark creates one executor for each worker by default, these executors are “fat.” They contain all the CPU cores and memory available to the worker node. Fat executors can be beneficial for certain use cases, such as when an application is processing a large amount of data or when managing several executors becomes a concern.

• Since a fat executor has more cores, more tasks can be run in parallel (typically 1 core = 1 task), which can improve application performance.
• An additional benefit of fat executors is enhanced data locality, as there is a greater chance of data being processed on a node where it is already stored. This reduces the amount of network traffic (data sent between workers), speeding up the application.

While there are benefits to using fat executors, there are potential downsides:

• As all the memory and CPU for a worker sit on one executor, there is potential for resources being underutilized if some cores or portions of memory remain unused.
• Fat executors have a lower fault tolerance in the event of an error, as all the resources for a worker are contained on a single executor. If that one executor goes down, the whole worker goes down.

Thin executors in Spark

In direct contrast to fat executors are thin executors. Thin executors are minimally sized, oftentimes containing a single CPU core (or a small number of cores) and a fraction of the memory available to a worker node.

• Similar to fat executors, thin executors also increase parallelism, in this case because there are more executors available.
• There is better fault tolerance due to the number of executors available in the cluster. If an executor goes down, it’s not the end of the world, and the amount of data being processed on each executor is small due to the limited memory on thin executors, so recomputation is easier.

Thin executors are not perfect either, and there are negatives:

• A high amount of network traffic occurs between the driver and executors on each worker node. Since thin executors have less memory and fewer CPU cores, there will be more data sent across more executors as the driver assigns tasks and receives the results from workers.
• For similar reasons, there is reduced data locality when using thin executors. More data is spread over more executors, and each executor has a smaller amount of memory, preventing it from storing a large quantity of data partitions locally.

Optimally sized executors in Spark

As the name implies, optimally sized executors are configured to contain the ideal amount of memory and CPU cores for each executor on a worker node. Optimal executors are the Goldilocks solution: not too big, not too small, just right. This can lead to improved application performance by potentially reducing the run time of the application while better utilizing the resources configured. Optimal executors are determined by following the rules below.

Rules for sizing optimal Spark executors

Sizing Spark executors correctly requires following a few best-practice rules:

1. Leave out 1 CPU core and 1 GB of RAM for the operating system per worker node.
2. Remove 1 executor (or 1 core and 1 GB of RAM) at the cluster level to account for resource management.
3. When calculating executor memory, leave out a certain amount to account for the memory overhead of internal system processes. The amount to leave out is MAX (384 MB, 10% of executor memory).
4. Ideally, have 3–5 CPU cores on each executor.

Example Spark configuration across 5 worker nodes

Given what we now know about executors, let’s walk through an example. We’ll use a sample Spark configuration with 5 worker nodes, each containing 12 CPU cores and 48 GB of RAM. Our base cluster looks like this:

After following rule 1, we are left with 11 cores and 47 GB of RAM on each worker node.

Across the cluster (all 5 nodes), we have:

Now, we follow rule 2. We could remove one full executor (which would likely be better for a thin executor case where we have many executors), but for this example, we will remove 1 GB of RAM and 1 core at the cluster level.

We want to use optimally sized executors across these 5 nodes and need to take into account rule 4, leveraging 3–5 cores per executor. We’ll choose 5 executors:

The Spark configurations set for this example would be as follows:

The following is a visualization of what the executors would look like in relation to the whole cluster, with each executor in purple:

Conclusion: Spark executor tuning matters

Spark executor tuning matters because performance, cost efficiency and reliability all hinge on how executors are configured. Ideally, this article provides a deeper understanding of what Spark executors are and how tuning them can lead to better performance and potential cost savings. As with many concepts in Spark, executor tuning is not an exact science and will likely require trial and error. This article should serve as an example that you can use to crunch the numbers and find the optimal configuration for your application. Enjoy tuning!

Originally published at https://www.capitalone.com.

This blog was co-authored by Rudra Sinha, Senior Manager; Andrew Baak, Principal Associate and Tatum Bair, Principal Associate Rudra Sinha, Andrew Baak and Tatum Bair work in the data engineering space and boast extensive experience in data engineering and technical leadership. As a group of data engineering leaders, their passion is to explain their deep data engineering knowledge, acquired through extensive research, concept proofing and countless implementations.

DISCLOSURE STATEMENT: © 2026 Capital One. Opinions are those of the individual author and are not necessarily those of Capital One. Unless noted otherwise, Capital One is not affiliated with, nor endorsed by, any third parties mentioned and is not responsible for the content or privacy policies of any linked third-party sites. Any trademarks and other intellectual property used or displayed are property of their respective owners.

Spark tuning: executor optimization for performance was originally published in Capital One Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Capital One, we are deeply committed to advancing the frontier of artificial intelligence (AI) to solve meaningful industrywide challenges.

A key part of this mission is fostering long-term multi-sector ecosystems and partnerships to advance the state of the art. Recently, we hosted our first-ever two-day AI Symposium in McLean, Virginia. The inaugural event was designed to deepen connections and foster insight-sharing between the scientific AI community, leading-edge startups and our own technology, data science and AI/machine learning leaders and partners.

A multi-sector approach

Across the two days, the symposium highlighted a critical shift in how we approach researching and building AI. Rather than siloing talent and insights within the confines of the university environment or the private sector, we must build sustainable, reciprocal models that strengthen both for broad societal benefit.

The AI Symposium showcased how academic research can play a defining role in enterprise without losing its scientific rigor.

Day 1: The Academic Summit

The first day focused on the latest breakthroughs in AI and related areas from top academics, applied scientists and engineering leaders. Key themes explored in these academic talks and discussions included:

Human-AI Interaction: Professors Lydia Chilton of Columbia University and Mohit Bansal, director of the University of North Carolina at Chapel Hill MURGe Lab, discussed challenges and opportunities related to trust in AI systems, including the confidence obstacles impeding productivity and how addressing said obstacles can improve real-world applications in medicine, education and beyond.

Creative Intelligence: Professors Heng Ji of the University of Illinois at Urbana-Champaign and Ellie Pavlick of Brown University explored how models can move beyond simple pattern-matching into complex reasoning to generate entirely novel solutions, alongside deep dives into how AI systems actually process information internally.

Responsible Decision-Making and Quantum: Multi-sector panels, including researchers like Dr. Shih-Fu Chang, dean of Columbia Engineering, and Professor Gaurav Sukhatme, director of Advanced Computing at the University of Southern California, discussed the responsible implementation of AI in finance, the need for multisector innovation and considerations for the intersection of AI and quantum computing alongside experts from scientific federal agencies.

The Academic Summit was enriched by the participation of academic leaders from Capital One’s formal partnerships, including the Capital One University of Southern California Center for Responsible AI and Decision Making in Finance; the Capital One Illinois Center for Generative AI Safety, Knowledge Systems, and Cybersecurity; the Columbia Center for AI and Responsible Financial Innovation; the University of Maryland Center for Machine Learning; the University of North Carolina at Chapel Hill MURGe Lab; the University of Virginia School of Data Science; the University of Virginia School of Engineering; and partners from the National Science Foundation and the Partnership on AI.

Day 2: The Frontier Forum

The second day focused on the enterprise, exploring how scientific breakthroughs can scale to create real business impact. Highlights included:

Economics of AI: Insights from Professor Jason Furman of the Harvard Kennedy School of Government focused on the emerging macroeconomic impacts of advanced AI.

Innovations in Infrastructure: Bryan Catanzaro of NVIDIA and Professor Randall Balestriero of Brown University and formerly Meta AI Research offered deep dives into open foundation models and accelerated infrastructure, and the applicability of world models to reliable AI in complex real-world parameters, respectively.

Agentic Coding: Boris Cherny and Laurens van der Maaten from Anthropic explored the future of software engineering and research through the lens of Claude Code.

Startup Showcases: Demos from Capital One Ventures startup partners highlighted the cutting edge of AI monitoring, data infrastructure and conversational applications.

Dialogues and connections facilitated by the Capital One AI Symposium are critically important drivers as we look to the next frontier of enterprise AI. By bringing together the brightest minds across academia, government, big tech, startups and our own enterprise, we are collaboratively building a more intelligent, autonomous and well-managed future.

We look forward to continuing these vital conversations and further fostering a collaborative ecosystem that attracts world-class talent to the frontier of AI and advances U.S. AI leadership.

Interested in joining the team that’s building the future of AI in finance? Explore our AI Careers page.

Originally published at https://www.capitalone.com.

DISCLOSURE STATEMENT: © 2026 Capital One. Opinions are those of the individual author and are not necessarily those of Capital One. Unless noted otherwise, Capital One is not affiliated with, nor endorsed by, any third parties mentioned and is not responsible for the content or privacy policies of any linked third-party sites. Any trademarks and other intellectual property used or displayed are property of their respective owners.

Insights from the inaugural Capital One AI Symposium was originally published in Capital One Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Capital One technologists are excited to participate in the 14th International Conference on Learning Representations (ICLR) taking place in Rio de Janeiro, Brazil, April 23–27, 2026. As a premier venue for deep-learning research, ICLR provides a vital forum for addressing the complexities of natural language and representation learning.

Capital One is participating as a gold sponsor and research contributor to discuss advancements in large language model (LLM) alignment, uncertainty quantification and the development of responsible, agentic systems. This work provides the foundational technical solutions necessary for the next generation of financial services.

Main conference research: AI safety and model reasoning

The following research, accepted to the ICLR Main Conference, examines the limits of how models reason, adhere to safety policies and quantify uncertainty. This section includes work from Capital One researchers, papers first-authored by 2025 Applied Research Interns and collaborative research with academic partners.

Alignment-Weighted DPO: A novel way to improve alignment in LLMs via reasoning
Capital One Authors: Mengxuan Hu (ARIP 2025), Vivek Datla, Anoop Kumar, Alfy Samuel, Daben Liu

Despite advances in alignment techniques like Direct Preference Optimization (DPO), LLMs remain vulnerable to jailbreak attacks. Our research, grounded in causal intervention, reveals that this vulnerability stems from “shallow” alignment, a lack of deep reasoning when rejecting harmful prompts. To bridge this gap, we introduce Alignment-Weighted DPO, a reasoning-aware post-training technique that identifies problematic reasoning segments during response generation. By targeting these specific vulnerabilities, our method improves robustness against diverse jailbreak strategies while maintaining overall model utility.

Uncertainty as Feature Gaps: Epistemic Uncertainty Quantification of LLMs in Contextual Question-Answering
Capital One Authors: Yavuz Bakman (ARIP 2025), Zhiqi Huang, Chenyang Zhu, Anoop Kumar, Alfy Samuel, Daben Liu

Quantifying epistemic uncertainty is critical for real-world contextual quality assurance. This study proposes a theoretically grounded approach that interprets uncertainty as “feature gaps” in hidden representations relative to an ideal model. By extracting features like context reliance and honesty, we form a robust uncertainty score. Experiments show a 13-point prediction-rejection ratio improvement over state-of-the-art methods with negligible inference overhead.

DynaGuard: A Dynamic Guardian Model With User-Defined Policies
Capital One Authors: Melissa Kazemi Rad, Bayan Bruss

While standard guardian models are limited to predefined harm categories, this collaboration with the University of Maryland introduces DynaGuard, a suite of dynamic models that evaluate conversational agent responses in multiturn settings based on user-defined policies, as well as DynaBench, a synthetically generated dataset with dynamic rules covering various industries and multiturn user-agent interactions. DynaGuard provides rapid detection of custom violations and a chain-of-thought option to justify outputs. It surpasses state-of-the-art guardrail models in accuracy and is competitive with frontier reasoning models on free-form policy violations.

mR3: Multilingual Rubric-Agnostic Reward Reasoning Models
Capital One Author: Genta Winata

Evaluation using LLM judges often fails to generalize to non-English settings. This work introduced mR3, a multilingual reward reasoning model trained on 72 languages and developed in partnership with Stanford University. It achieves state-of-the-art performance on multilingual benchmarks while remaining significantly smaller than larger models, demonstrating an effective strategy for building high-quality multilingual reward models.

BioTamperNet: Affinity-Guided State-Space Model Detecting Tampered Biomedical Images
Capital One Author: Premkumar Natarajan

Subtle manipulations in biomedical images can compromise experimental validity. In partnership with the University of Southern California (USC), this research introduces BioTamperNet, which uses affinity-guided attention inspired by state space model approximations to detect duplicated regions. By integrating lightweight linear attention mechanisms, it identifies tampered regions and their source counterparts more accurately than competitive forensic baselines. This methodology may be applicable to financial services in the context of fraud detection and image verification.

μLO: Compute-Efficient Meta-Generalization of Learned Optimizers
Capital One Author: Charles-Etienne Joseph

Learned optimizers (LOs) often struggle to optimize unseen tasks. In collaboration with Mila, Samsung AI Lab, Concordia University, Sorbonne University and Université de Montréal, this research derived the maximal update parametrization (μP) for two LO architectures and proposed a meta-training recipe for μ-parametrized LOs (μLOs). This method substantially improves meta-generalization to wider, deeper and longer training horizons compared to standard parametrization.

Workshop tracks: Privacy, synthetic data and forecasting

Our workshop participation addresses the intersection of privacy, synthetic data and time-series forecasting. This includes work from our Applied Research Internship Program and our funded university-based Academic Centers of Excellence.

Evaluating LLM Simulators as Differentially Private Data Generators (The 2nd Workshop on Advances in Financial AI)
Capital One Authors: Nassima Bouzid, Dehao Yuan, Nam Nguyen, Mayana Wanderley Pereira

LLM-based simulators offer a path for generating complex synthetic data, but their ability to reproduce statistical distributions from DP-protected inputs remains a question. This study finds that while these simulators achieve promising utility, they exhibit significant distribution drift due to systematic LLM biases. Addressing these failure modes is essential before LLM-based methods can handle the rich user representations required for financial simulations.

Decoupling Identity From Utility: Privacy-by-Design Frameworks for Financial Ecosystems (The 2nd Workshop on Advances in Financial AI)
Capital One Authors: Ifayoyinsola Ibikunle, Tyler Farnan, Senthil Kumar, Mayana Wanderley Pereira

This paper positions differentially private (DP) synthetic data as a robust framework for building responsible agentic systems in finance. We examine direct tabular synthesis and DP-seeded agent-based modeling, arguing that the latter is essential for autonomous finance. It provides a “safe gym” for training agents, enabling fairness auditing and robustness testing while adhering to rigorous formal privacy guarantees.

Zero-Shot Multivariate Time Series Forecasting Using Tabular Prior Fitted Networks (Time Series in the Age of Large Models [TSALM] Workshop)
Capital One Authors: Mayuka Jayawardhana (ARIP 2025), Doron Bergman, Nihal Sharma, Nam Nguyen, Mohammadkazem Meidani

This research recasts the multivariate time series forecasting problem as a series of scalar regression problems. Doing so provides a twofold benefit: First, we can leverage tabular foundation models (which have been remarkably successful in tabular regression tasks) in a zero-shot fashion to serve as forecasters. Second, our reformulation allows for interchannel interaction, going beyond the current standard of decomposing the multivariate forecasting problem into independent univariate subproblems.

EPSVec: Efficient and Private Synthetic Data Generation via Dataset Vectors (Workshop on Navigating and Addressing Data Problems for Foundation Models [DATA-FM])
Capital One Authors: Erin Babinsky, Alfy Samuel, Anoop Kumar

Developed through our USC-Capital One Center for Responsible AI and Decision Making in Finance (CREDIF) program, EPSVec is a lightweight DP synthetic data generation method. It steers LLM generation using dataset vectors — directions in activation space that capture the distributional gap between private data and public priors. EPSVec extracts and sanitizes steering vectors just once and then performs standard decoding. This method decouples the privacy budget from generation, enabling high-fidelity synthetic samples even in low-data regimes with reduced computational overhead.

Your Model Diversity, Not Method, Determines Reasoning Strategy (Workshop on Logical Reasoning of Large Language Models)
Capital One Authors: Moulik Choraria (ARIP 2025), Anirban Das, Supriyo Chakraborty, Berkcan Kapusuzoglu, Chiahsuan Lee, Kartik Balasubramaniam, Shixiong Zhang, Sambit Sahu

This study investigates how the allocation of compute budget between exploration (breadth) and refinement (depth) impacts LLM reasoning. We argue that the optimal allocation strategy depends on a model’s “diversity profile”-the spread of probability mass across solution approaches-and it must be characterized before any exploration strategy is adopted. We formalize it by decomposing the reasoning uncertainty and deriving conditions under which tree-style refinement outperforms parallel sampling.

Connect with Capital One at ICLR 2026

If you’re attending the conference in Rio de Janeiro, we invite you to visit our booth to engage with our researchers and authors.

• Visit our booth: 408
• Explore our research: Dive deep into our latest advancements in AI and machine learning.
• Discover career opportunities: Learn about exciting applied research career paths at Capital One for researchers and engineers passionate about AI and join our world-class team.
• Learn about our student and grad internships: Put your knowledge and skills to work in our 10-week to two-year graduate programs innovating new products and creatively solving the problems that impact our customers and our business.
• Engage with our team: Meet our researchers and AI experts, explore how we’re shaping financial services with patented AI and discuss what’s next for AI in finance.

Originally published at https://www.capitalone.com.

DISCLOSURE STATEMENT: © 2026 Capital One. Opinions are those of the individual author and are not necessarily those of Capital One. Unless noted otherwise, Capital One is not affiliated with, nor endorsed by, any third parties mentioned and is not responsible for the content or privacy policies of any linked third-party sites. Any trademarks and other intellectual property used or displayed are property of their respective owners.

NLP research foundations at ICLR 2026 was originally published in Capital One Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

In 2005, long before my time at Capital One, I was a Marine corporal in Iraq. I supported network communications for my squadron, and because of my role, I had to bunker down when attacks occurred. Not fight, just be on high alert and ready to fight if necessary.

When a mortar round or rocket crossed the perimeter and hit the base, I felt it. Often, I felt like a sitting duck. Yet, despite what was happening around me, I had to be ready to support comms for my unit. I had to ensure it was available and secured-or zeroized if all else failed. In those days, though, I only worried about the outside threat-the physical one pounding on my door.

Why now? The evolution of cyber threats

We’ve come a long way since the early days of Operation Iraqi Freedom. Do those types of threats still exist in the world? You bet they do. However, we now have sophisticated cyber threats to deal with too. We have ransomware, DDoS attacks, social engineering, phishing attacks, deepfakes and the list goes on for a solid mile. Depending on the attack, these can come from the outside or the inside.

There are numerous reasons why these threats exist, but many stem from rapid advancements in technology and a growing internet presence. DataReportal.com indicates that 5.35 billion people were using the internet in 2024. This is great for many industries but scary when considering the blast radius of one infiltrated app that millions of people could use.

Recent data breaches, like the MOVEit data breach in 2023, show how alarmingly simple and wide-scaling an attack can become if executed from the right angle in today’s world. In this attack, hackers obtained access to the MOVEit file transfer software. Then, they leveraged a vulnerability to retrieve sensitive data from tens of millions of people across a multitude of companies. That data was further utilized to collect ransom money from execs at big companies. The impact of this breach is still being felt today.

The traditional security struggle bus

I’m a network security engineer, but I’ll say it: Traditional network security struggles against modern threats. Conventional models rely heavily on a solid perimeter but allow for ease of movement for inside personnel. This is often due to cost or to improve performance.

Despite these struggles, the number of attacks and the number of directions they can come from are staggering. It’s not enough to build an “outside” firewall, a DMZ and an “internal” firewall your users sit behind. Today, we obviously need a more adaptive and resilient security model.

Say hello to zero trust network security

I’m sure you’ve heard of it by now, but zero trust network security (ZTNS) is a different way of thinking. Instead of assuming trust within the network, ZTNS is founded on this principle: “Never trust, always verify.” Every access request, whether it originates from inside or outside the network, is subject to strict verification.

The “Never trust, always verify” approach

In ZTNS, trust is never implicit. Each user and device must continually prove their legitimacy through stringent checks. This is akin to the rigorous identification checks at a military checkpoint-no one gets through without proper clearance. Want in? Badge, business and clearance level, please!

Key components of zero trust

1. Identity-Based Access Controls: Only authenticated and authorized users can access resources.
2. Microsegmentation: Slicing the network into smaller segments to contain potential breaches, much like setting up multiple secure zones within a base.
3. Continuous Monitoring: Constant vigilance over network activity to detect and respond to threats in real time.
4. Least Privilege Access: Users have the minimal access required, limiting potential damage if an account is compromised.

Benefits of zero trust

• Enhanced Security Posture: With zero trust, each access attempt faces scrutiny, making it harder for attackers to roam once inside.
• Protection Against Insider Threats: Zero trust limits even trusted insiders’ actions. Essentially, you have to be verified to do things.
• Improved Visibility and Control: Zero trust allows organizations to monitor network traffic closely, which helps detect anomalies.

Implementing zero trust

Zero trust is not something you magically implement overnight. It demands a thorough review of your current infrastructure. It demands vulnerabilities be identified. Furthermore, it requires a network audit to pinpoint where current security mechanisms fall short.

Best practices for implementation

• Identity Management: Use strict identity and access management protocols.
• Network Segmentation: Create secure zones within the network to contain potential threats.
• Encryption: You need this for your sensitive data-in transit and at rest.
• Multifactor Authentication (MFA): Require multiple forms of verification for critical resources.
• Continuous Monitoring: Use advanced monitoring tools to identify and respond to unusual activities in real time.

SASE and zero trust

Secure access service edge (SASE) combines networking and security to support zero trust principles. It uses five key capabilities:

• Software-defined wide area network (SD-WAN)
• Secure web gateway (SWG)
• Cloud access security broker (CASB)
• Firewall as a service (FWaaS)
• Zero trust network access (ZTNA)

There are many providers and solutions for these capabilities. Still, if we hone in on ZTNA, you may recognize common solutions like GlobalProtect by Palo Alto Networks, Zscaler Private Access (ZPA) and Cisco Secure Client (formerly AnyConnect). Do any of those sound familiar?

Real-world examples

In his book “Zero Trust Security Demystified,” L.D. Knowings points out several organizations that have successfully embraced zero trust. He mentions big companies like Accenture, Cloudflare and Akamai, a well-known CDN with a dynamic environment. Even Cisco is mentioned, which should be familiar to many folks in the network space. They use their own SASE architecture, in fact.

Companies that have adopted zero trust report better threat detection and faster incident response times, as every access request undergoes verification. Many of their cloud infrastructures are secured, their attack surface is reduced, and there is limited ability for malware or bad actors to move laterally on the inside. Not to mention, their data is protected, and they can respond faster to new threats.

Challenges of zero trust

Zero trust can be tricky to implement, not to mention resource-intensive-costs, complexity and user experience all play a role in that. To overcome these types of challenges, organizations should:

• Plan Thoroughly: Hash out a comprehensive plan that involves all necessary stakeholders, business requirements, target state and so on.
• Invest Wisely: Draft an RFP for solutions that meet your requirements and target state. Invest in the tools and technology that best meet your organization’s needs.
• Educate Users: Ensure that everyone-senior leaders, internal engineers, app developers and definitely your end users-understands your new tech and protocols.

Balancing security with user experience is vital for successful adoption. There are many vendors that offer SASE solutions, some all-in-one and some only pieces of the bigger zero trust puzzle. Over time, there will be more, but here are some well-known ones: Palo Alto Networks, Fortinet, Netskope and Cisco.

The future of zero trust

As cyber threats evolve, zero trust will remain crucial in cybersecurity. Dynamic cloud environments, like the one we have at Capital One, make this especially important. However, with tech like AI and machine learning, we’ll be able to enhance zero trust by enabling better threat detection and response. With these, we can sift through data faster, find suspicious patterns or anomalies and be more proactive in our security stance.

Let’s not forget about the role of IoT either. Tim Cook, the CEO of Apple, said: “The Internet of Things is creating a new world where everything is connected and can be controlled remotely.” This is exciting, yet scary when you consider how fast things can hop on the internet with minimal security provisions. Of course, zero trust can help secure IoT devices by requiring each device to be authenticated and monitored, minimizing the risk of IoT-based attacks.

Conclusion

If I learned anything from my beloved time in the Marines, it would stem from this mantra: “Improvise, adapt and overcome.” That “adapt” part is crucial for today’s digital environment. By moving beyond outdated models and embracing zero trust, organizations can adapt and ensure more robust defenses against cyber adversaries.

In the evolving landscape of cybersecurity, zero trust is the new standard, and it’s the path that companies in the modern world must begin to take. This is the path toward resilient, perhaps even antifragile, networks. Adapting and staying vigilant are essential, as complacency is not an option.

Zero trust. Over and out.

Originally published at https://www.capitalone.com.

Authored by Jerry Bair, Lead Platform Engineer, Network Core Security. Jerry Bair is a network security engineer supporting customer enablement for Capital One Network Observability. He ventured into the field after getting out of the U.S. Marine Corps in 2006 and found his way to Capital One in 2013. When he’s not tech-ing out at Capital One, he challenges himself with Spartan races and DEKA events.

DISCLOSURE STATEMENT: © 2026 Capital One. Opinions are those of the individual author and are not necessarily those of Capital One. Unless noted otherwise, Capital One is not affiliated with, nor endorsed by, any third parties mentioned and is not responsible for the content or privacy policies of any linked third-party sites. Any trademarks and other intellectual property used or displayed are property of their respective owners.

Zero trust revolution: Why legacy network security fails was originally published in Capital One Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here’s a recap of Capital One’s presence at NVIDIA GTC 2026, which took place March 16–19 in San Jose, California. As always, GTC was a landmark event for the future of technology. As generative AI moves from experimental prototypes to enterprise-scale production, Capital One was excited to take part in the conversation.

With two featured sessions, a high-traffic booth presence, and strategic discussions with industry peers, our team shared how we are leveraging NVIDIA’s accelerated computing power to build a more enlightened banking experience.

This year, our leaders took the stage to discuss the shift from simple LLM chat interfaces to complex, multi-agentic systems capable of handling sophisticated conversational workflows.

Featured sessions

Building Proprietary Multi-Agentic AI Workflows for Consumer Banking

Explore how Capital One is leveraging its proprietary multi-agentic AI framework to improve the speed, effectiveness and documentation of customer service calls concerning fraud. This solution shows promise in enhancing both the human associate experience as well as the customer experience by advancing quality reviews and agent productivity while meeting rigorous business standards for accuracy, reliability and governance.

Featuring:

• Milind Naphade, SVP, Head of AI Foundations, Capital One
• Ritesh Soni, MVP, Data Science, Retail Bank, Capital One

Key Takeaways:

• Multi-Agent Orchestration: We demonstrated how combining customized foundation models with multi-agent orchestration reduces summarization latency while preserving critical details.
• Customization and Scalability: The solution’s underlying multi-agentic framework was originally built to support a car-buying solution and later applied to supporting customers with fraud resolution. This “build once, reuse extensively” mindset encourages associates from any corner of the bank to identify manual processes and pull from our centralized “tech stack” to build solutions.

Watch the speaker session >

Accelerating Enterprise AI: From Infrastructure to Agentic Systems

Our second session delved into the “five-layer cake” of AI-energy, chips, infrastructure, models and applications. Learn firsthand from Capital One engineering leaders how they’re building distributed data pipelines to curate high-quality datasets that enable laser-focused foundation models for financial applications.

Featuring:

• Brian Nguyen, Sr. Engineering Manager, Capital One
• Nick Resnick, Lead AI Engineer, Capital One

Watch the speaker session >

Conversations on the floor and in the press

Beyond the session halls, our booth received over 1,200 visitors and served as a hub for deep dives into MLOps, data privacy and the evolving landscape of open-source AI. Following the conference, the Wall Street Journal’s CIO Journal featured Capital One in a discussion on why leading companies are leaning into open-source models despite the complexities.

Looking ahead

GTC 2026 made one thing clear: The era of agentic AI has arrived. For Capital One, this means moving beyond simple automation to create systems that can reason, collaborate and execute complex tasks on behalf of our customers and associates.

By combining NVIDIA’s cutting-edge hardware with our modern tech stack and data ecosystem as well as our deep domain expertise, we are continuing to define what’s possible in the next generation of financial services.

Interested in joining the team building the future of AI in finance? Explore our AI Careers page.

Originally published at https://www.capitalone.com.

DISCLOSURE STATEMENT: © 2026 Capital One. Opinions are those of the individual author and are not necessarily those of Capital One. Unless noted otherwise, Capital One is not affiliated with, nor endorsed by, any third parties mentioned and is not responsible for the content or privacy policies of any linked third-party sites. Any trademarks and other intellectual property used or displayed are property of their respective owners.

Highlights from NVIDIA GTC AI Conference 2026 was originally published in Capital One Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

The specter of generating a secure random number can unnerve a software engineer of any experience level. The apparitional subtleties of the myriad available approaches can tremble even the practiced hand of a seasoned cybersecurity professional. And as with the cryptographic domain’s other spindly fingers, secure random number generation demands precisely correct implementation-otherwise, the security of the entire system at question might collapse. But against the severe implications of a poor choice, a rudimentary understanding of where random numbers come from suffices to make an informed decision and effectively mitigate the security risk associated with an inadequate source of random numbers.

For engineers, cybersecurity professionals or anyone generating encryption keys or setting up a process to do so or governance around it, this article will demystify the process of selecting a random number generator by explaining the varying levels of security that different solutions can offer in different contexts.

Understanding entropy and randomness

Briefly, a few key terms will aid in understanding the nuances of random number generation.

Random number generators

The output of a function is called random-and similarly, the function can be called a true random number generator, or RNG-if given all inputs to the function there is no effective computational method to forecast its output. In other words, the output of the function does not follow any predetermined algorithm.

Pseudorandom number generators

A pseudorandom number generator (PRNG), on the other hand, is a function that, given a seed value, produces a sequence that passes statistical tests for randomness. PRNGs are different from RNGs because, given an identical seed and context, they will produce an identical sequence of numbers. However, they can suffice in many cases, provided an attacker has no means by which to discover the seed.

Random bit generators and entropy

The National Institute of Science and Technology (NIST) defines both of these concepts in computational terms. According to SP 800–90, a random bit generator (RBG) is defined as “a device or algorithm that outputs a sequence of binary bits that appears to be statistically independent and unbiased.” As such, RBGs can be either RNGs or PRNGs. To distinguish between the two, NIST defines non-deterministic random bit generators and deterministic random bit generators (DRBGs) as their respective computational equivalents.

Entropy is a related concept that refers to the level of uncertainty in the output of a random function. NIST defines entropy as “a measure of the disorder, randomness or variability in a closed system.” Entropy is measured in bits-a fair coin flip has exactly one bit of entropy; an unfair coin flip has a little bit less entropy, since there is less uncertainty in the outcome; and a roll of a six-sided die has about 2.5 bits of entropy, since there is more uncertainty in the outcome. As the name implies, it is analogous to entropy in the context of thermodynamics. A source of entropy is an RBG acting as a source of uncertainty in the same way a coin or die might.

Cryptographically secure language built-ins

How standard libraries generate random bits

Desktop or server computers generate random bits by feeding output from a source of entropy through a DRBG. For example, computers might accumulate a pool of entropy consisting of things like mouse movements and temperature fluctuations from the central processing unit (CPU) or specialty entropy-generation chips like Intel’s digital random number generator. Upon user request, a DRBG siphons a few bits from the entropy pool and transforms them into a usable sequence of random bits.

Why virtual environments add risk

The cryptographically secure RBG from any language’s standard library uses this type of random bit generation-entropy collection from the hardware running it. Standard library RBGs are ubiquitously recommended by online forums, enterprise policies and government agencies, and they are secure in a wide range of cases. But when working in a virtualized setting, blindly following broadly scoped guidelines and collecting entropy from local hardware can leave your application vulnerable to attack.

Problems with local entropy in virtualized infrastructure

Virtualized infrastructure includes almost anything deployed using a cloud provider, but it could mean a fleet of dynamically provisioned virtual machines in a local data center or even on a single server. Of course, architects must examine each application individually to determine the level of risk each may pose, but two problems bedevil secure local entropy generation on most deployments of virtual hardware.

Entropy starvation at boot time

The first issue is a lack of entropy. Many large software deployments often involve dynamic scaling, which means frequent and automated provisioning of new servers or virtual machines. Soon after boot, an operating system may not have had enough time to collect sufficient entropy to generate secure random bits. Operating systems work around this problem in a number of different ways, which means that a generation call may not actually generate a random bit sequence but instead a predictable vestige of a starved entropy source. For example, in some older, diskless Linux distributions, the kernel’s RBG relies purely on reasonably predictable system events, making the initial entropy state highly predictable.

Entropy spying and manipulation on shared hardware

The second issue pesters systems even more persistently and resists simple solutions. On virtualized hardware, any other user of a shared physical server can read or influence the entropy collected by that particular server. It has been demonstrated in laboratory environments that entropy spying and manipulation permit an attacker to effectively predict RBG output on virtual machine- and container-based deployments across cloud platforms and operating systems. In another case, as a common work-around of the problem of boot-time entropy starvation, many Linux distributions save their final entropy state to the disk on shutdown as a seed to be loaded at reboot. But after the operating system has been shut down, anyone with access to a shared physical disk might be able to read the seed data.

Entropy spying is an extreme danger for software on virtualized infrastructure. Any key generated on a device compromised this way is itself compromised; thus, generating secure random bits on virtual hardware requires a completely novel solution.

A practical solution: Using hardware security modules

What HSMs are and why they’re secure

Hardware-based RBGs are the best source of entropy available on a regular computer, but specialized hardware exists. In particular, for secure random bits when local entropy doesn’t suffice, choose a hardware security module (HSM).

HSMs are special-purpose servers that are primarily used for key management in security-sensitive sectors like government, health care and finance. Capital One uses HSMs to store our most secure keys. HSMs ship with purpose-built entropy generation hardware that is significantly more sophisticated than the entropy sources supplied with general-purpose consumer CPUs. These purpose-built chips are protected from any spying or meddling, generate enormous amounts of entropy, and are nearly impossible to compromise.

Unfortunately, HSMs are often expensive to buy and maintain, and access to HSMs both physically and over the network must be tightly restricted to keep the attack surface on these sensitive machines as small as possible. But as a work-around of the apparently prohibitive cost and security, major cloud platforms provide a way to get secure random bits from an HSM on demand without actually requiring that you purchase and maintain one yourself.

Cloud KMS alternatives from AWS, Azure and GCP

To generate high-quality random bits, AWS Key Management Service (KMS) provides a simple GenerateRandom application programming interface (API) call, Azure Key Vault has Get Random Bytes and Google Cloud Platform (GCP) KMS offers GenerateRandomBytes. None of these API calls requires the creation or management of a dedicated HSM resource, and all three are billed at just $0.03 per 10,000 requests. Random bits generated using these functions are immune to the cloud vulnerabilities that haunt system RBGs.

A perfect solution: Quantum random number generation

For enterprises living on the cutting edge of security that wish to use in-house HSMs directly, some newer HSMs have begun incorporating exciting new quantum random number generator (QRNG) chips. QRNG chips source their entropy from measurements of systems governed by the rules of quantum mechanics. Quantum random number generation, on the other hand, is protected by the universe itself-measurements of quantum systems are unpredictable as a law of physics. No attacker, even given perfect knowledge of a QRNG chip and all its inputs, can predict its output.

QRNG chips have limited availability today. Integration and cost challenges will likely prohibit on-prem adoption for a while, though cloud-based solutions through the providers of other key generation APIs may be available sooner. And because QRNGs are new, they remain under scrutiny for the side-channel and implementation-specific attacks that imperil all real-world cryptographic systems. But don’t despair if you can’t get access to one yet; modern DRBGs are good enough-so good that QRNGs don’t provide any practical advantages in terms of security (at least not any that are known to the public).

Each application is unique: Matching entropy sources to risk

Depending on the context, securing an application may only require a standard hardware-based entropy source or it may require a bleeding-edge QRNG chip. Since attacks on hardware-based entropy generation are possible, we must assume nation-state threat actors are executing them. So for the most security-sensitive random numbers, like AES or RSA keys protecting sensitive data, using random bits generated by a cloud provider’s HSMs is prudent. But for other applications, such a high level of caution may not be necessary.

Ultimately, each application needs an individual security review, and the source of any required random bits should be examined and evaluated as part of a comprehensive threat model. It is easy to find oneself caught in the Lethean maelstrom of online forums that immerse the topic of random number generation in verbiage that implies a mystery too deep to unravel. But-as with any other security decision-it is a set of practical and understandable criteria that determines the appropriate choice.

Originally published at https://www.capitalone.com.

Authored by William Cabell, Lead Software Engineer, Cyber Intelligence Engineering. I’m a lead software engineer and cybersecurity professional who finds fulfillment in solving hard, open-ended problems. I’ve built resilient engineering cultures and led the development of large-scale software platforms in the cryptography and cyber intelligence domains.

DISCLOSURE STATEMENT: © 2026 Capital One. Opinions are those of the individual author and are not necessarily those of Capital One. Unless noted otherwise, Capital One is not affiliated with, nor endorsed by, any third parties mentioned and is not responsible for the content or privacy policies of any linked third-party sites. Any trademarks and other intellectual property used or displayed are property of their respective owners.

Secure random number generation on virtual hardware was originally published in Capital One Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Academic partnerships are an essential component of Capital One’s approach to advancing AI research. Our collaboration with the University of Maryland (UMD), initiated in 2017, showcases this commitment. Through support for computer science initiatives, faculty, student development and research, Capital One has engaged with UMD over the years to address challenges and opportunities in financial services.

Fostering dialogue and collaboration

On March 3, 2026, Capital One and UMD joined together to host the “Agentic Systems in Industry” workshop to facilitate dialogue on the biggest open problems in the AI space. The event featured a series of lightning talks followed by small-group discussions between UMD faculty and Capital One researchers.

A key theme that emerged from the discussion was the challenges that can arise with recommender systems, specifically value alignment. Avoiding unintended consequences may require scalable evaluations for highly complex tasks and an effort to address control theory issues in feedback loops. Across industries and use cases, explainability remains of critical importance.

Another theme centered on the challenges of summarizing large-scale datasets and integrating knowledge from disparate sources. Advancing synthetic data generation and high-fidelity data curation will require further research. Additionally, research must evaluate the applicability of new methods, such as tabular and graph foundation models, to large-scale datasets. These issues underscore the ongoing necessity of ensuring interpretability and comprehensible explanations.

“I thoroughly enjoyed interacting with the UMD academic community,” said Giri Iyengar, Vice President of Specialist Models at Capital One, who was in attendance. “The experience was invigorating, and the exchange of ideas was much needed for us to continue advancing the field.”

Cultivating the next generation of AI practitioners

Cultivating the next generation of AI talent is a critical pillar of successful campus-based research. The event included a poster session where Capital One researchers engaged with students on open research problems. The workshop concluded at the Capital One Tech Incubator, located in the UMD Discovery District, providing a final opportunity for community and connection among workshop attendees, university administrators and graduate students.

By working alongside institutions like UMD, Capital One can drive innovation through joint research and cultivate the next generation of AI practitioners. These strategic collaborations are crucial for unlocking AI’s full potential to transform financial services and deliver superior experiences for our customers.

Originally published at https://www.capitalone.com.

DISCLOSURE STATEMENT: © 2026 Capital One. Opinions are those of the individual author and are not necessarily those of Capital One. Unless noted otherwise, Capital One is not affiliated with, nor endorsed by, any third parties mentioned and is not responsible for the content or privacy policies of any linked third-party sites. Any trademarks and other intellectual property used or displayed are property of their respective owners.

Capital One and UMD host agentic systems workshop was originally published in Capital One Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Capital One technologists are excited to participate in the 19th Conference of the European Chapter of the Association for Computational Linguistics (EACL 2026) taking place in Rabat, Morocco, on March 24–29, 2026. As a premier venue for computational linguistics, EACL provides a vital forum for sharing research that addresses the complexities of natural language.

Our technical presence at EACL 2026 — comprising five Main Conference papers and one Industry Track paper — is rooted in a clear research priority: building AI systems that remain stable and transparent when reasoning through complex, real-world logic. By focusing on instruction compliance, automated fault detection and Retrieval-Augmented Generation (RAG), this work provides the foundational technical solutions necessary for the next generation of financial services. By participating in this conference, Capital One continues to contribute to global advancements in AI safety, system reliability and the creation of explainable AI architectures.

Technical foundations: Advancing AI reliability and reasoning

The following research examines the limits of how large language models (LLMs) adhere to complex constraints and identifies why agentic systems can sometimes falter over long horizons. This section includes work from Capital One researchers and first-authored papers from the 2025 Data Science Internship Program (DSIP).

Deconstructing Instruction-Following: A New Benchmark for Granular Analysis of Large Language Model Instruction Compliance Abilities
Capital One Authors: Alberto Purpura, Li Wang, Sahil Badyal, Eugenio Beaufrand, Adam Faulkner

Reliably ensuring LLMs follow complex instructions is a significant challenge. Part of the problem is how we measure it, since benchmarks often conflate instruction compliance with general task success. This paper introduces a novel evaluation framework and a dynamically generated dataset with thousands of prompts, each containing up to 20 application-oriented constraints to enable granular analysis of the instruction-following abilities of LLMs. The research demonstrates that compliance varies significantly by constraint type and position, revealing specific model weaknesses like primacy and recency effects. These insights assist in developing LLMs for rigorous environments that require strict adherence to complex instructions.

RAFFLES: Reasoning-based Attribution of Faults for LLM Systems
Capital One Authors: Chenyang Zhu, Jingyu Wu, Kushal Chawla, Youbing Yin, Nathan Wolfe, Erin Babinsky, Daben Liu

Identifying the exact point of failure in multicomponent LLM agentic systems can be a persistent challenge. This paper presents RAFFLES, an evaluation architecture that uses iterative reasoning to automate fault detection. By utilizing a central “judge” to investigate faults and specialized “evaluators” to verify that reasoning, RAFFLES identifies failure points with significantly higher accuracy than existing baselines. This work offers a path toward enhancing human review with automated diagnostics for autonomous systems.

DF-RAG: Enhancing RAG for Question Answering by Balancing Relevance and Diversity of Retrieved Chunks
Capital One Authors: Saadat Hasan Khan (DSIP 2025), Jingyu Wu, Youbing Yin, Erin Babinsky, Daben Liu

Retrieval-augmented generation (RAG) performance is often limited by redundant information during the retrieval phase. This work, led by a 2025 Data Science Intern, introduces DF-RAG, a pipeline that dynamically balances retrieval diversity for each query at test time. Using a maximal marginal relevance (MMR)-based scoring mechanism and LLM-driven planning, DF-RAG recovered up to 90% of the gap between standard retrieval and the theoretical upper bounds for information recall in multi-hop benchmarks.

ART: Adaptive Reasoning Trees for Explainable Claim Verification
Capital One Authors: Sahil Wadhwa, Himanshu Kumar, Guanqun Yang (DSIP 2025), Abbaas Alif Mohamed Nishar, Pranab Mohanty, Swapnil Shinde, Yue Wu

The opacity of LLM decision-making remains a barrier to adoption in select fields. This paper proposes ART (adaptive reasoning trees), a hierarchical method for claim verification. The process branches root claims into supporting and attacking arguments, which are adjudicated via a pairwise tournament by a judge LLM to derive a transparent, contestable verdict. ART’s structured reasoning consistently outperforms chain-of-thought (CoT) methods in explainable AI tasks.

Scalable personalization: Profile-grounded synthetic data

Bridging the gap between fundamental research and industry application is a priority for Capital One’s academic partnerships. This work was developed at the USC-Capital One Center for Responsible AI and Decision Making in Finance (CREDIF), a joint research center that advances state-of-the-art research and foundations for algorithmic, data and software innovations in responsible AI and its applications to finance.

GRAVITY: A Framework for Personalized Text Generation via Profile-Grounded Synthetic Preferences
Capital One Authors: Wenqing Zheng and Daniel Barcklow

Personalization in LLMs typically requires manual human feedback. This paper introduces GRAVITY, a framework for generating synthetic, profile-grounded preference data. By integrating cultural and psychological frameworks (such as the Big Five OCEAN traits), GRAVITY synthesizes preference pairs to guide personalized content generation. In evaluations with 400 users, GRAVITY achieved higher preference gains than standard fine-tuning, providing a scalable path for personalization without relying on manual annotation.

Applied engineering: Adaptable life cycles for generative AI

Our participation in the Industry Track focuses on the practicalities of developing and maintaining AI systems at scale within complex operational environments.

Lessons from the Field: An Adaptable Lifecycle Approach to Applied Dialogue Summarization
Capital One Authors: Kushal Chawla, Alfy Samuel, Shixiong Zhang, Ayushman Singh, Chenyang Zhu, Erin Babinsky, Jonah Lewis, Keasha Safewright, Pengshan Cai, Sambit Sahu, Sangwoo Cho, Scott Novotney

Summarizing multiparty dialogues is a critical industrial capability, yet static benchmarks rarely reflect the evolving requirements of real-world use. This industry case study shares insights from developing an agentic summarization system, covering evaluation methods for subjective tasks, component-wise optimization and the impact of upstream data bottlenecks. The work provides a road map for building summarization systems that remain adaptable to evolving business needs and technical constraints.

Learn more about Capital One’s research at EACL 2026

Researchers and authors are available throughout the conference to discuss these advancements and their application to the financial services landscape. To learn more about AI and machine learning at Capital One, visit our careers page.

We look forward to a fantastic EACL 2026 and an engaging conference in Rabat!

Originally published at https://www.capitalone.com.

DISCLOSURE STATEMENT: © 2026 Capital One. Opinions are those of the individual author and are not necessarily those of Capital One. Unless noted otherwise, Capital One is not affiliated with, nor endorsed by, any third parties mentioned and is not responsible for the content or privacy policies of any linked third-party sites. Any trademarks and other intellectual property used or displayed are property of their respective owners.

Capital One NLP Research at EACL 2026 was originally published in Capital One Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article captures a recent conversation with Shehzad Mevawalla, EVP, Head of Capital One’s Enterprise Data Technology organization. Shehzad joined Capital One in March 2025 with more than 36 years in data architecture, large-scale systems and AI, including roles at industry heavyweights Amazon, FICO and NCR/Teradata. Shehzad leads technology and engineering strategies for Enterprise Data, partnering closely with Capital One’s Chief Data Officer to continue to modernize and transform the company’s data ecosystem. We caught up with Shehzad as he approaches his one-year anniversary with the company to learn more about what attracted him to Capital One, his priorities for data technology and its role as a critical enabler for AI, and personal leadership philosophies that inform how he leads high-performing enterprise technology organizations.

With a longstanding career in data and technology, what attracted you to this role at Capital One? How does it align with your professional goals and interests?

As I researched Capital One’s culture and history, I realized that Capital One is really a technology company that also happens to be a bank. The founding principles of the company are based on leveraging deep analytics and technological advancement to deliver new, unique and personalized experiences for customers. What also stood out was Capital One’s relentless drive for reinvention. This isn’t a company satisfied with the status quo; it constantly seeks to evolve. That commitment to innovation, coupled with a strong emphasis on employee well-being and development, made this role incredibly attractive.

During my long tenure at Amazon, I was extremely fortunate to work across a wide variety of areas with some amazing people. My experience there, particularly across large-scale data, risk management and machine learning, provided me with a highly relevant background. This deep alignment between my specific skills and experiences and the technical requirements and strategic vision of this role at Capital One was an excellent match. The connection was clear, and I’m genuinely thrilled to be here and to be contributing to Capital One’s continued success.

What have been your top priorities in your first year with the team?

Joining Capital One as the head of Enterprise Data Technology at such a pivotal time is incredibly exciting. The company has already made impressive strides in consolidating its operational and analytical data into a single, high-quality and well-managed data platform. This multi-year journey, spanning data collection, verification, publication, storage and usage, has been executed with remarkable care and insight.

My absolute first priority has been to connect with people, which includes building strong relationships with my teams, our partners across the organization and our customers. Concurrently, I’ve dedicated significant time to learning our platforms and services, and the underlying data itself-how it’s structured, managed and ultimately used to drive value. This dual focus on people and technology ensures our organization can lead effectively from an informed and collaborative position.

I’ve also been focused on examining everything we do through the lens of the customer. This includes identifying the many strengths of our current system so we can amplify and double down on those successes. Equally important is uncovering any gaps or points of friction that might hinder efficiency or lead to missed opportunities, then quickly addressing these areas to enhance our overall effectiveness.

Looking ahead, a high priority for me is to further increase the footprint of AI within our data systems. My goal is to make our data truly conversational, enabling more intuitive and powerful interactions for our users. This involves leveraging advanced AI techniques to unlock new insights, automate processes and create a more dynamic and accessible data environment for everyone.

Over the course of your career, what has changed about the way companies use data and how they think about managing and leveraging data, especially to power their AI aspirations?

The way companies use data has significantly evolved over time, especially with the rise of AI. As I think about it, three major changes have driven this evolution:

1. The exponential growth in data scale. The shift from traditional databases to cloud-based technologies gives companies unlimited and cost-effective storage and compute capabilities.
2. The capability potential of unstructured data. Previously, unstructured data was largely inaccessible for decision-making without expensive processing. However, new models have made it queriable, allowing it to be incorporated into business decisions.
3. This combination of structured and unstructured data capabilities represents a revolutionary shift, opening new frontiers for data utilization and value creation that were previously unattainable.

You’re a software engineer by trade. Can you elaborate on how that training has manifested into the way you think about the systems, software and the developer experience today?

My training as a software engineer is at the core of how I approach systems, software and the developer experience today. Leveraging both foundational technical thinking and deep understanding of the journey from concept to production allows me to make informed decisions and connect complex ideas, even when navigating new technological frontiers.

The developer experience is currently evolving as new models for code generation signal a fundamental shift in how systems are built. Although these tools are in their early stages, they promise to significantly enhance productivity and accelerate engineering throughput, helping to transform ingenuity into tangible products. Throughout this evolution, core development expertise and engineering proficiency will remain essential.

Can you share your most important learnings from leading speech and audio technologies for Alexa?

When I began my journey with Alexa, I was new to the highly specialized and technical field of speech science. To succeed, I had to quickly learn and adapt, embracing new frontiers through a mix of curiosity and confidence in my ability to master complex technical knowledge. The most significant milestone in this role was our work on moving from traditional machine learning to speech LLMs. In doing so, we delivered truly conversational and human-like interactions for Alexa and then further generalized it for other voice-based applications as well.

I’m excited that we’re now applying similar approaches to achieve natural-language interactions across the business at Capital One. This is especially true as some of the most exciting trends in data technology right now revolve around unstructured data and the increased accessibility of data use through AI. AI-powered data analytics tools are emerging that can generate datasets or answers to questions, which promise to revolutionize data management and utilization. This is a key area of focus for us as we leverage the power of foundational LLMs to build AI into our work every day. In doing so, we’re continuing to amplify the huge value of data by making it easily accessible and usable through a natural and intuitive interface for both businesses and customers.

Finally, are there any other notable career highlights and/or your passions outside of work you’d like to share?

Professionally, every career change I’ve made has been to very different areas and has always been about expanding my own learning or expertise. At Amazon, for example, I took on roles in supply chain as well as speech, both of which are highly technical fields that had a steep learning curve for me. As you go through your career, keeping an eye on interesting areas you’d like to learn more about will enhance your overall understanding and personal development. At Capital One, I am learning all about the banking industry and how Capital One serves its customers. There’s no better way to do that than by understanding the data behind it, which gives you a really well-rounded view.

Personally, I have been a big car enthusiast since I was very young, and my love for cars has continued to this very day. I continue to spend my off-hours, when not with my children and family, enjoying this hobby.

Originally published at https://www.capitalone.com.

DISCLOSURE STATEMENT: © 2026 Capital One. Opinions are those of the individual author and are not necessarily those of Capital One. Unless noted otherwise, Capital One is not affiliated with, nor endorsed by, any third parties mentioned and is not responsible for the content or privacy policies of any linked third-party sites. Any trademarks and other intellectual property used or displayed are property of their respective owners.

Meet Shehzad Mevawalla, EVP of Enterprise Data Tech was originally published in Capital One Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last June, we had the opportunity to attend Droidcon NYC. This is one of the premier conferences to learn about the cutting-edge tech in Android and how others from different companies are solving hard problems and delivering quality solutions. Last year was special since Capital One was a silver sponsor for the conference and we had 49 associates from all over the U.S. that attended.

Here are some top takeaways we took from the conference and wanted to share more broadly.

1. Handling configuration changes in Jetpack Compose

A key takeaway was managing configuration changes smoothly in Jetpack Compose. For frequent changes, like on foldables, you can opt out of full Activity recreation. First, add android:configChanges="orientation|screenSize|..." to your AndroidManifest.xml. Then, in your Composables, use rememberSaveable to preserve simple UI state across these changes. This avoids the visual disruption of a full restart. For the standard Android behavior where the Activity is recreated, ViewModels remain the correct tool to hold and persist complex data.

2. AI in Android development: Smarter responses and documentation

A great way to make AI give better responses is to link your team’s documentation to provide it with richer context. Likewise, AI agents can create a draft of your documentation for you (though make sure to review it). While agent use isn’t yet approved for use at Capital One, be on the lookout for when it gets approved, and continue using Gemini and Copilot in the meantime.

3. The rise of server-driven UI in Android apps

Server-Driven UI (SDUI) is great for quick design updates and A/B testing, as it lets you change the UI without needing a new app release, often leading to smaller native app sizes and faster load times with good network conditions. However, SDUI struggles with complex animations, map interactions and purely static screens because it introduces network dependency and can add significant backend complexity, potentially impacting performance on slower connections. It’s a powerful tool for dynamic content and rapid experimentation, but you need to carefully consider the trade-offs in terms of complexity and specific UI requirements.

4. Coroutine exception handling to prevent app crashes

By default, when a child coroutine fails, the exception propagates upwards, canceling its parent and all other sibling coroutines within that scope. To prevent an app crash from this unhandled exception, use a CoroutineExceptionHandler in the context of a top-level coroutine, like one launched from viewModelScope or rememberCoroutineScope(), because it stops exception propagation and avoids a program crash, preventing any leaks.

5. Understanding Compose rendering and UI tree management

When @Composable functions are invoked, they contribute nodes to an in-memory tree that represents the UI. This helps track state and efficiently update changes.

6. Using SubcomposeLayout for dynamic and adaptive UIs

If you are making UI that isn’t fully known until runtime (ex: SDUI or loading an image that you don’t know the dimensions of), you can use SubcomposeLayout to first measure certain children, and then, based on those measurements, compose and measure other children. SubcomposeLayout is particularly useful for Server-Driven UIs and dynamically sizing elements based on their contents, allowing for flexible and adaptive layouts that wouldn’t otherwise be achievable with standard Compose layouts that follow a strict measure-then-layout-then-draw order.

7. Coroutines vs. threads: Why Kotlin wins for concurrency

The lightweight and non-blocking nature of coroutines allows for a graceful cancellation at different points of their execution, which makes management of concurrent tasks easy and efficient. Threads, on the other hand, are difficult to cancel gracefully since they often perform blocking I/O or computations without explicit “cancellation points,” meaning a cancellation request can go unnoticed while the thread is stuck waiting for an external event, potentially leaving shared resources in an inconsistent state and leading to deadlocks if it’s abruptly terminated mid-operation.

8. Managing ExecutorService and lifecycle in Android

It’s crucial to shut down an ExecutorService in Android because its threads won’t stop automatically, leading to memory leaks and battery drain. You must manually call shutdown() when the component using it, like a ViewModel, is destroyed. For modern apps, however, it’s far better to use Kotlin Coroutines with a CoroutineScope, as they handle this lifecycle management automatically and prevent leaks by design.

9. Avoid breaking structured concurrency in coroutines

A parent coroutine always waits for its children to complete. This means it is imperative that we use the correct scope and context because creating a new CoroutineScope starts an independent coroutine that is not a child of the original scope, thus breaking structured concurrency.

10. Building custom layouts in Jetpack Compose

Custom layouts in Jetpack Compose give developers fine-grained control over measurement and placement, leading to better performance and more efficient UI rendering. They help avoid unnecessary recompositions by handling size and position logic in the measurement phase. This makes them especially valuable for complex or dynamic UIs where precision and optimization are critical.

11. Exploring Kotlin multiplatform and cross-platform integration

Even though we don’t currently use KMP, it enables us to share core business logic across Android, iOS and other platforms, reducing code duplication and ensuring consistency. This boosts developer efficiency, accelerates time-to-market and improves code quality through shared testing.

12. Scaling real-world Android apps under pressure

Scaling real-world apps under fire requires making tough architectural decisions quickly while maintaining app stability and user trust. It involves balancing short-term fixes with long-term scalability, often under high-pressure conditions like outages, rapid growth or organizational shifts.

Looking back at Droidcon NYC 2025

The most memorable part of Droidcon NYC 2025 wasn’t just the technical insights — it was connecting with so many Capital One associates and fellow Android developers from across the community. As a silver sponsor, Capital One was proud to support last year’s event and contribute to conversations shaping the future of Android development.

Originally published at https://www.capitalone.com.

This blog was co-authored by Ariella Mendel, Software Engineer; Madona Wambua, Principal Software Engineer and Oleksandra Kurbanova, Software Engineer

Ariella Mendel has been a Native Android Developer at Capital One for over three years, working on card fraud and disputes. With a graduate degree in Computer Engineering from Northwestern, she is passionate about applying hardware knowledge to improve the performance and scalability of Android applications. Outside of work, she enjoys running, hot yoga and gardening. Madona Wambua is a Principal Software Engineer with over a decade of experience in software development. She currently contributes her expertise at Capital One working on the mobile app, where she has been a key team member for the past eight months. Recognized as a Google Developer Expert in Android and a Women Techmakers Ambassador, Madona is deeply committed to advancing the tech community. She is also the author of the Modern Android 13 Development Cookbook, a comprehensive guide offering over 70 practical recipes for modern Android development using Kotlin and Jetpack Compose. Beyond her engineering role, Madona is pursuing an EMBA at Cornell University, reflecting her dedication to continuous learning and leadership. Oleksandra Kurbanova is an Android Software Engineer at Capital One with prior experience in data engineering and full-stack development.

DISCLOSURE STATEMENT: © 2026 Capital One. Opinions are those of the individual author and are not necessarily those of Capital One. Unless noted otherwise, Capital One is not affiliated with, nor endorsed by, any third parties mentioned and is not responsible for the content or privacy policies of any linked third-party sites. Any trademarks and other intellectual property used or displayed are property of their respective owners.

Top 12 takeaways from Droidcon NYC 2025 was originally published in Capital One Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.