Chime Innovation & Technology Culture

What types of products or services does your engineering team build? What problem are you solving for customers?

At Chime, our engineering teams build the systems that power modern banking for millions of members. These are products like Chime Card, Chime+, MyPay, SpotMe and more that help everyday Americans spend, save, build credit and access short-term liquidity. Underneath it all is ChimeCore, our proprietary ledger and transaction-processing platform that lets us move fast while keeping members safe.

Our job isn’t just to ship more features; it’s to help everyday Americans achieve financial progress. Every optimization — whether shaving milliseconds off a transaction or catching fraud a little faster — directly reduces stress for our members and helps them on their financial journeys. That’s the mission that drives every line of code.

Tell us about a recent project where your team used AI as a tool. What was it meant to accomplish? How did you use AI to assist?

AI is now woven into how we build. Engineers across Chime use coding assistants to generate tests, draft documentation and summarize pull requests — always with human review before anything ships. About 27 percent of our code was written with AI in June 2025 and automation across build, test and deploy shortened complex change cycles from roughly 12 weeks to three days.

The result isn’t just more output; it’s better engineering. AI handles the repetitive scaffolding so developers can focus on architecture, reliability and security — raising both velocity and quality at the same time.

What would that project have looked like if you didn't have AI as a tool to use? 

Before we adopted AI widely, engineers spent hours — or days — on setup, documentation and reviews: necessary work that drains creative energy. Today, those loops are largely automated, letting teams spend time where it matters most — design, safety and member impact.

The bigger change is cultural. We now think in systems: humans, AI and data are all instrumented for transparency. AI drafts, humans verify, metrics validate. That feedback loop has shifted us from managing keystrokes to managing outcomes.

At Chime’s scale, that impact is enormous — faster innovation, safer releases and engineers spending more time solving real problems that help real people.

What does a typical day for you at Chime look like?

Data Science is crucial to a company’s success. Data Scientists manage relationships with stakeholders and translate business problems into analytical insights, process automation, experimentation and machine learning solutions.

Since I joined Chime over four months ago, I have been on a financial security cross-functional team to provide data science support to MyPayTM, one of our biggest new products. I’m currently working with another Data Scientist on developing a new ML model for MyPay.

ML models shine the most when they provide business value to the stakeholders. To launch a product like MyPay, many teams have to chime in, so I spend a lot of time understanding the updates on the legal, compliance and design sides — and especially on the product, risk and engineering fronts.

In addition, I spend most days conducting exploratory data analysis, engineering features, creating machine learning models in the model development phase, evaluating the model performance, updating the stakeholders in the later phase of the model development and, more often than not, troubleshooting different issues and solving problems.
 

Tell us about a project you’re working on right now.

When SpotMe* a fee-free overdraft product, was launched in 2019, most banks still charged overdraft fees. But over the years, many banks have dropped them. Chime’s member-centric trailblazer has made a positive impact on consumers.

MyPay is also a game changer. It empowers members by providing them with funds ahead of payday. It is my great privilege to contribute to a product that has such tremendous potential to help members with my data science expertise.

Different data scientists may have different answers to this, but I love framing ML problems and designing end-to-end ML solutions. Thinking about how MyPay relates to other products at Chime and how MyPay brings value to Chime is very interesting to me. I also really enjoy brainstorming different model approaches with other Data Scientists and cross-functional partners.

One potential challenge of working on a super high-impact product is staying informed when there are many moving pieces. Thanks to Chime’s culture of encouraging documentation and teams sharing updates in public, the challenge becomes a learning opportunity.

What’s the culture like on your team? How do Chime team members grow their knowledge and connect?

I am a part of the data science and machine learning team and based in San Francisco. In addition to the financial security data scientists I work with day-to-day, I also work with data scientists from other business functions and ML platform engineers. Those of us based locally also enjoy having lunch together in the SF office.

Our team is very supportive of individual growth and learning from each other. We have brown bag Thursdays and other technical learning sessions to stay updated with what other data scientists and engineers are up to.

Chime also supports the culture of learning and sharing. We have biweekly experimentation hours, demo hours, insight hours, research hours, etc., so all Chimers can keep up to date with other departments’ work.

My favorite learning experience so far is Hack Week. We had three days to turn an idea into a product, and it was a thrilling experience. That Friday, we had five hours of demos. It was so inspiring to see all the wonderful ideas and realize that I get to work with so many brilliant and humble colleagues. Fun fact: MyPay was once a Hack Week idea!

What practices does your team employ to foster innovation, and how have these practices led to more creative, out-of-the-box thinking?

Since joining Chime, I’ve been consistently impressed by how the company fosters innovation. Just a month in, my manager and teammates encouraged me to participate in the annual hackathon. Chime’s hackathons bring together hundreds of “Chimers” and spark not only creative product ideas but also new connections across teams that continue to help me to this day.

Within my core team, we also host Innovation Days, where we tackle pressing challenges and find solutions that could scale or automate our work and reduce the team’s burdens. These small side projects don’t just help us; they free up more of our time to develop innovative products that improve our customers’ experiences as well. Beyond hackathons and Innovation Days, I’ve found that onsites, guild meetings, Donut chats and cross-functional workshops instill a strong sense of learning and collaboration. These moments spark deeper understanding, foster alignment and inspire fresh ways of problem-solving in us.

How has a focus on innovation increased the quality of your team’s work? 

Our focus on innovation enabled us to build data-driven dashboards that began as a side project. As part of the quality engineering team, we transformed these dashboards into impactful tools that provide essential, actionable insights and aggregate key metrics, offering a comprehensive view of product quality and health. Through these efforts, we’ve not only improved efficiency but also developed a stronger culture of ownership, collaboration and data-driven thinking.

Another example born out of a hackathon was our automated ticket triage process. What once required hours of manual effort across teams is now handled with greater speed and accuracy, significantly reducing overhead and improving response times.

How has a focus on innovation bolstered your team’s culture? 

Having the support and bandwidth at both the team and organizational level to prioritize innovation has helped us move more quickly toward our goals. It has created a team culture and environment where people are always ready to roll up their sleeves and improve how we work, which in turn fosters a strong sense of collaboration. Events like hackathons, guild onsites and guild meetings provide great opportunities to bond and boost morale, especially important while working in a remote environment. These practices strengthen our team culture, making it easier to connect and support one another. 

Whether we’re pairing on technical design docs or jumping into an impromptu huddle to brainstorm solutions, it has taught us all to value flexibility and shared ownership, which helps us stay creative, productive and aligned. Innovation at Chime isn’t just an initiative — it’s a mindset, and I’ve felt empowered to be a part of it from day one.

Chime fosters a hands-on innovation culture, exemplified by a recent AI agent–building workshop where product managers designed and deployed real solutions to everyday challenges. By encouraging experimentation and practical application of emerging technologies, the company empowers employees to turn ideas into impactful tools used across teams.

“There’s a lot of talk about AI, but not enough time to actually explore it. I wanted this to be a space where people could build, experiment, and walk away having learned something that makes them better at their jobs.

Chime takes a culture-first approach to AI adoption, choosing to encourage experimentation rather than mandate usage. This philosophy emphasizes trust and intrinsic motivation, positioning innovation as something driven by empowered employees rather than top-down directives.

“Other companies may be expecting AI fluency right away. We wanted to create space for curiosity. We knew that if we led with recognition, we’d help build the confidence people need to try something new—and it’s working.”

Chimers aren’t waiting to be told what to do with AI. They’re experimenting, sharing, and learning together through the AI Voyager Program. They’re not just adopting new tools—they’re shaping how those tools fit into our mission.

“Innovation sparks more innovation. What makes Voyager special is that it elevates the everyday builders—the ones who test, share, and improve how we work. People can even nominate themselves, privately. And we talk about it during onboarding, so new hires know: you don’t have to wait to contribute. You can start building on day two.”

Chime applies AI as an enablement tool to increase efficiency and scale content production while maintaining human oversight. This reflects a balanced approach to AI adoption that prioritizes productivity and quality rather than automation alone.

“We use AI to scale smarter, not to replace people. We brought in AirOps to power our content workflows, running more than a hundred AI-driven steps from keyword discovery to briefing and optimization, with editors ensuring every piece meets our quality bar.”

Chime integrates AI search into its broader growth strategy, treating platforms like ChatGPT and Gemini as core discovery channels alongside traditional search engines. This reflects a forward-looking approach to marketing and technology, where emerging platforms are embedded into long-term strategy rather than treated as experimental.

“We treat AI search as an extension of our organic growth strategy, right alongside Google and YouTube.”

Chime embeds data into its product development process, with teams proactively considering measurement, experimentation, and outcomes from the earliest stages. This reflects a mature data culture where data is integral to innovation and decision-making.

“Every product requirements doc has a data component. The teams are experimenting, demoing new products, thinking upstream about what kind of data they’ll need to measure success. That’s rare.”

How does your team encounter challenges with scalability? 

We often think of scalability in terms of strategy, as in horizontal and vertical scaling: either you add more power to the machines you’re running or you add more machines — and often it’s both. I tend to think of both horizontal and vertical scaling in terms of software systems, not just servers. Horizontal means spreading out the system or its responsibilities, like sharding your database or splitting that monolith into microservices. Vertical means increasing the power in the system. 

I work in Chime’s risk engineering organization. Our software sits between our members and the rest of Chime’s product, providing assessment and assurance in response to risk. An example of this is Authentication, the area I work most in. Our job is to ensure that each account can only be accessed by the member who owns it. To us, scalability means managing a ton of incoming requests and vetting them with other parts of risk engineering. We do this mostly with a few different approaches to horizontal scaling and we have some examples of vertical scaling thrown into our software system.

How do you guide your team through this process? 

One way my team approaches scaling is through software and application layers — scaling the software design and architecture appropriately as the domain grows. We try to follow the common wisdom and design our systems so that dependencies are loosely coupled. Best design intentions are only part of the process; software systems are always changing with new requirements, goals, products and features. Some part of scaling means keeping up with that changing system in a way that maintains flexibility as the system’s responsibilities expand.  

Let’s use a classic database scaling example to illustrate: running out of integers. It’s happened to most companies above a certain size, but we only hear about it when it causes an incident. Just like monitoring your sql database to make sure you are prepared with a solution *before* you run out of integers, enabling appropriate scaling at the software level requires awareness of the state of your domain, and the ability to prioritize opportunities to expand appropriately, before it’s too late, and your previously loose dependencies end up backed into a corner between all the cool stuff you’ve been iterating so quickly on.

What tools are the go-tos? 

We rely heavily on monitoring tools like Datadog to keep eyes on our systems.  We have a very slick CI/CD system that rolls back automatically when canaries fail. Chime started as a Ruby on Rails shop. Some parts of Chime have shifted to using other languages like Go to facilitate vertical scaling in the software layer and add speed to the system. 

In the authentication domain, one approach we take to scaling is to qualify the requests we receive and effectively limit the number of requests we ultimately have to deal with at deeper layers of the stack. Specifically, there are rate-limiting strategies and step-up strategies we can set at the front of the request cycle to try to filter out bot traffic, ingenuine login attempts or even just login attempts that are more likely to result in fraud.

Beyond that we love to lean on NoSql like DynamoDB, which has scaled well in the risk domain broadly. I find that DDB modeling demands are an appropriate fit for our domain and a useful tool in guiding us towards designing appropriate space between services.

Why is broad-based data literacy important for Chime? 

It allows teams to ask and answer questions like: What are our measurable goals, how are we performing and how can we quantify opportunities and progress on our initiatives and operations? 

Achieving data literacy depends on relevance, access and reliability. Relevance is when metrics relate to business objectives and people are aligned across the organization. Access is the discoverability — of data, reports, dashboards — and the ability to self-serve. Reliability is when people can trust the data: Is it timely? Are metrics defined consistently? Are there checks on the data pipelines and ownership of quality issues?

At Chime, we rely on being a data-literate organization because our understanding of our members relies upon it. By providing and consuming relevant, accessible and reliable data, we can trust that we're delivering features and services that our members need. 

For example, we recently announced additional support for members affected by Hurricane Ian, which required the collaboration and input of many teams. This called for timely and reliable access to data.

What programs, initiatives or training did you use to promote data literacy across the organization?

To promote data literacy across the organization, we've invested in the areas that we believe are critical to achieving it: relevance, access, and reliability.

Our analytics teams work with business stakeholders to define relevant metrics, then use them to scope new initiatives. Metrics are also the basis of experiments we conduct in the launches of new products, services and campaigns. They ensure that metrics are consistent across the organization and identify areas to improve our definitions and alignment.

Our business intelligence and data engineering teams support discoverability, tooling and reliability. We aim for self-service, reliable data and reporting products that can be used for all of our operational and product efforts.

Finally, supporting our internal users is a critical part of our efforts. Training and onboarding programs are tailored to a person’s role, and we answer questions related to the data and tools via office hours and on-call support. Finally, we continue to extend our documentation, such as metrics definitions, FAQs and guides, so that teams are able to move quickly, independently and consistently in their engagement with data and reporting tools.

What new capabilities have data literacy unlocked for your team?

Many companies go through a period of developing metrics. Still, efforts often happen in siloes — leading them to a need for canonical definitions so that teams can truly work together on the same objectives. 

By focusing on data literacy and investing in relevance, especially in canonical definitions and single source-of-truth data tables, we've allowed more teams to work together more effectively — because they know they're referring to the same metrics.

In addition, this has made it easier to establish common dashboards and enabled the wide adoption of self-service tools across our company. This, in turn, has helped empower individuals instead of relying on the data organization to support them.

But we’re not done. For instance, we're investing in common practices and tools for experimentation and look forward to enabling even more fundamental changes in broad-based data literacy at Chime.

Engineering Manager Rahul Gupta said taking breaks between big projects allows employees to recover at fintech company Chime. Stepping back also enables engineers to evaluate work holistically and reflect on the recent project. During projects, carving out time to fix problems also helps alleviate stress.

How do you address and prevent developer fatigue among your team? 

I first focus on reducing context switching for our engineers. The thing about context switching is that it gets in the way of focused work, reduces quality and can blur the lines of priority for a developer, leading to fatigue. 

Once a feature or product is live, I work to put space between projects for developers on my team. As a manager, I’m responsible for ensuring that developers have time to breathe between large pieces of work. When something’s done, they need time to monitor it and make sure it’s successfully rolled out and bug-free before starting on the next big project. This limits stress and helps people evaluate their work holistically and also encourages people to apply learnings from one project to another instead of just steamrolling ahead.

When it comes to the work your team members do and the technology they interact with, how do you ensure members of your team stay engaged and challenged?

It’s stressful if a local dev environment is flaky. We carve out time as a team to fix those problems, using things like retro to surface challenges in the process and put energy towards eliminating any friction for our developers. As a leader, I’m continuously working to help create space for those kinds of issues to get worked on to limit frustration or burnout.

When you recognize signs of fatigue or burn out in a developer, what do you do to address it? 

At Chime, we believe the most important part of addressing fatigue is engaging with your team members rather than ignoring the issue. For me, that starts with clarifying what’s going on — making sure I’m not jumping to conclusions or misinterpreting the signals I’m receiving. Then, on a case by case basis, I’ll work with developers on my team to figure out what needs to happen, whether it be time off or scaling back on work.