Yuri Misnik, Chief Technology Officer, inDrive – Interview Series

Yuri Misnik is the Chief Technology Officer at inDrive, where he leads the company’s global technology strategy. With more than two decades of international experience, Misnik has built and led high-impact technology programs across cloud, financial services, and large-scale digital transformation.

Before joining inDrive, he held senior roles at Microsoft and AWS. He later served as Digital CIO at HSBC, CIO at National Australia Bank, and Group CTO at First Abu Dhabi Bank, where he modernized complex, highly regulated environments through cloud, Agile, DevOps, and product-centric engineering models.

Misnik began his career in aerospace engineering, contributing to the design of the Boeing 787 before moving into software engineering and online trading systems. Equally fluent in legacy platforms and modern distributed architectures, he is known for bridging foundational systems with cutting-edge innovation.

At inDrive, he is focused on building the systems, teams, and platforms that will power the company’s next phase of global growth.

inDrive is a global mobility and urban services platform that connects users with drivers and service providers across ride-hailing, delivery, and other on-demand services. Founded in 2013, the company operates in over 48 countries and more than 1,000 cities, with hundreds of millions of app downloads worldwide. Its core differentiator is a peer-to-peer pricing model that allows passengers and drivers to negotiate fares directly, rather than relying on algorithmic pricing, aiming to create more transparent and fair transactions. Beyond transportation, inDrive has expanded into areas like intercity travel, courier services, fintech offerings, and even grocery delivery, positioning itself as a broader “super app” focused on accessible and equitable urban services.

You began in mathematical modelling and finite element analysis before moving through Microsoft, AWS, HSBC, and National Australia Bank, and now you’re leading AI transformation at inDrive. How has that journey shaped the way you think about building AI systems that are technically ambitious but still grounded in fairness, resilience, and real-world constraints?

I started my career in applied mathematics and finite element analysis, which is fundamentally about understanding where your model breaks down, rather than celebrating where it works. That mindset is exactly how I approach AI systems today.

At Microsoft and then AWS, where I spent over a decade, I learned what happens when you build platforms at global scale. You assume systems will degrade, networks will fail, components will behave unexpectedly. At inDrive, operating across more than 1,000 cities in 48 countries, that thinking has proven to be absolutely vital.

HSBC and National Australia Bank (NAB) brought a different lens. At HSBC I was building retail digital capabilities across dozens of regulatory regimes. At NAB I drove the cloud transformation, moving critical banking applications to AWS. In those environments, every technology decision carries regulatory, reputational, and financial consequences. An AI or ML model that can’t explain its decisions in a way a regulator or customer can understand is not an asset but a liability. 

A product should reflect people’s needs, not demonstrate the complexity of your stack. That principle is what keeps technical ambition grounded in fairness and real-world constraints.

That means building AI systems that inform and assist, for example by recommending a fair price without removing control from the people in the marketplace.The throughline across all of this is simple: technical ambition without operational discipline is just a demo. My career has been a progression from “can we design or build this?” to “should we deploy this, and what happens when it fails at 3am in a market where the stakes are real?” That’s the lens I bring to inDrive. 

Most platforms use AI to set prices. inDrive uses negotiation. So how does machine learning actually fit into your model and where across the platform is it delivering the most value without compromising the transparency that makes inDrive different?

AI at inDrive is not just about pricing; it is embedded across the entire business, spanning marketing and growth, super app  personalisation, customer support, geospatial intelligence, internal tooling, fraud prevention and more. Over 80% of our workforce uses a variety of AI tools from customer support and marketing to coding and analytics. AI is doing significant work in the surrounding infrastructure – in 2025 we’ve achieved a 14% ETA accuracy improvement compared to 2024 with the help of our deep learning models. So when people ask about AI and pricing, it is important to understand that it is just one dimension of a much broader capability. 

inDrive was founded in Yakutsk to combat unfair, collusive taxi pricing. Our core competitive identity is this peer-to-peer negotiation model — riders propose, drivers accept, counter, or decline. This open bidding flow is fundamental. What AI does is act as decision support around that human-negotiated price. If you look at traditional surge pricing models – they are a black box. The user sees a multiplier and has no recourse. In our model, the rider sees a suggested price, the driver can accept or counter, and the rider decides whether to accept or wait for another offer. ML makes these suggestions smarter and more contextually relevant based on supply, demand, distance, traffic, and time, but the negotiation mechanism preserves user agency. We also use ML to help drivers understand when and where earnings are stronger.We’re using AI to reduce information asymmetry between both parties, not to exploit it.

What does an “AI-first super app” actually mean in practice at inDrive and which parts of the platform are the most natural fit for AI today: marketplace matching, safety, customer support, financial services, or something else?  

Most companies that say “AI-first” mean they’ve added a chatbot. That’s not what we’re doing.

AI-first means AI sits in the operating layer of the platform, not the feature layer. Every product decision – from marketplace matching to customer support to credit scoring – starts with the question: what data do we have, and how should intelligence shape this experience? Unlike legacy super apps that grew before the AI era, we’re embedding these capabilities from the ground up as we scale across eight verticals: ride-hailing, intercity trips, courier, freight, grocery delivery, urban services, and financial products.

In terms of natural fit, marketplace matching and pricing intelligence is the core engine – better matching means higher utilization, which means better economics for both drivers and riders. Trust and safety is also a critical area: real-time anomaly detection, driver verification, and fraud prevention.

We operate in 48 countries and dozens of languages. AI-powered support – not just chatbots, but intelligent triage, auto-resolution of common issues, and multilingual capability – is both a cost and quality multiplier.

Financial services through inDrive.Money is where AI has helped us create a new value proposition for customers – in this case, our drivers. We’re using ride data, earnings patterns, and platform behavior to build alternative credit models for drivers that traditional banks cannot replicate with standard credit data alone. It is already live in Mexico, Colombia, Brazil, Indonesia, and Peru.

We also use AI for accessibility and inclusion – simplifying interfaces for users with lower literacy or disabilities. In many of our markets, it’s a requirement for reaching the addressable population.

The super app multiplier is that each additional vertical enriches the data graph. A rider who also uses grocery delivery and driver lending gives us a 360-degree behavioral picture. That makes every individual service smarter – but only if the data foundation and governance are right, which is the hard part.

inDrive is especially strong in emerging and frontier markets, where operating conditions can vary dramatically. How do you design AI systems that perform well across regions with very different infrastructure, payment habits, regulatory environments, and user expectations?

The difficulty lies in creating a unified model that performs reliably across 48 countries and over 1,000 cities in 8 distinct regions. We address this with a single, highly configurable platform where the majority of the work we do for new country launches have been configuration changes, not new code. This focuses our engineering effort on local requirements: driver verification, document validation, and government database integrations. 

Our architecture uses multiple AWS regions and a multi-availability zone environment that eliminates single points of failure. Our DevOps platform is highly automated, which helps our growing engineering teams in Pakistan, Egypt, and Asia Pacific operate with the same standards as our European teams. We are also building engineering capacity in Latin America, where we have significant business operations to better serve this market over time with nearby engineering presence. 

You’ve led large cloud and digital transformation efforts at institutions like HSBC and NAB. What lessons from highly regulated financial environments are proving most valuable as inDrive expands into services like fintech and builds more AI-driven decision systems?

Three lessons from HSBC and NAB transfer almost directly.

First, auditability and controls around data are not optional. In banking, every critical data element, every decision that affects a customer must be surrounded by appropriate controls which protect integrity and consistency. Everything needs to be traceable and explainable. And in the digital world you need to combine speed with controls, meaning all regulatory requirements need to be automated from the start. So, you are starting to think about regulatory requirements and controls as a software product, removing manual work and relying on automation everywhere.

Second, data governance precedes data science. At NAB and HSBC, I learned that the biggest bottleneck for AI is never the model – it’s the data. Who owns it? Is it clean? Is it consented? Is it properly lineaged? At inDrive, scaling from ride-hailing into financial services means our data governance has to mature rapidly. If you build the AI before the governance, you accumulate technical and regulatory debt that becomes exponentially harder to pay down.

Third, operational resilience matters more than model performance. Banking taught me that a 99.9 percent accurate model that fails catastrophically in the 0.1 percent case is worse than a 95 percent accurate model with graceful degradation. In our case, a false positive on fraud detection that locks a driver out of their earnings can destroy trust. You design for the failure case, not the happy path.

An advantage inDrive has over traditional fintechs is that we have continuous behavioral data on the borrowers. We know how frequently they drive, their acceptance rates, their earnings patterns, their reliability signals. That offers more robust signals for credit worthiness than a point-in-time FICO score or bank statement. But this advantage only materializes if we build the governance and fairness frameworks to use it responsibly, which is where the banking muscle memory is invaluable.

Many companies talk about keeping “humans in the loop,” but that phrase often stays vague. At inDrive, where do you believe human judgment should remain non-negotiable even as agentic workflows and automation become more capable?

I have a simple principle: automate the repeatable; keep humans on the irreversible. If a wrong decision is cheaply reversible, automate. If it can destroy trust, livelihood, or safety, human judgment stays.

Pricing authority is the most obvious example and the one that defines inDrive. The human – both the rider and the driver – always has the final say on price. This is non-negotiable regardless of how sophisticated our AI recommendations become. The moment we take that away, we become just another algorithmic platform, losing what differentiates us. That is architectural.

Safety escalations is another clear case. We automate first-level content moderation and support at scale. Trained on millions of texts, our AI system processes over two-thirds of ride-hailing chats to quickly detect, flag, and protect customers from inappropriate language. But when a situation is genuinely ambiguous or has significant consequences for someone’s livelihood, a human makes the call. Automation should intelligently filter cases, ensuring human judgment is only applied when truly valuable. The cost of a false negative is someone’s safety. You cannot automate that and maintain accountability.

Our broader principle is that AI should support human judgment, act as a teammate, not a substitute.

Market entry and regulatory adaptation require human judgment because they’re inherently contextual. No AI system should autonomously decide how we operate in a new regulatory environment. And account-level decisions – permanent bans, dispute resolution, appeals – require human judgment because the context is always richer than what the data captures.

The mistake many companies make is treating “human in the loop” as a phase they’ll eventually automate away. For the categories I’ve described, that’s the wrong framing. They’re cases where human judgment is structurally appropriate, and will remain so.

One of the hardest parts of scaling AI is not model performance but operational discipline: data quality, governance, monitoring, and cost control. What has been the biggest obstacle in turning AI from isolated use cases into an operating layer across the business?

Everyone gives the polite answer: data quality. That’s true but insufficient. The real obstacle is organizational. The hardest thing is not any single technical problem, but the transition from a culture of individual AI experiments to a culture of systematic AI operations. That shift requires changing how teams think about ownership, accountability, and measurement. 

When you treat AI as a set of isolated initiatives, each team builds its own pipeline, its own data access patterns, its own understanding of what “quality” means for their model. But when you want AI to be a horizontal operating layer touching pricing, safety, support, geo, personalisation simultaneously, you need shared foundations.

That includes a unified semantic layer with consistent metric definitions, shared data quality framework, model management infrastructure with embedded MLOps practices, and common security policies.

The often-underestimated cost dimension is also vital. We provide teams visibility into actual costs (per ride, per transaction, storage) to help improve accountability, which drives better engineering decisions. For example, storage optimization allowed us to reduce geo-data costs, significantly lowering per deal infrastructure cost as a result. The level of improvement we have seen is only possible when cost ownership is decentralized and embedded in the teams, not managed centrally as an afterthought.

Another significant challenge in using AI for internal operations. Automating chaos only yields chaos. Therefore, we are actively working with internal teams to formalize their work, describing their processes clearly and cleaning up outdated documentation. While not novel, these foundational steps are crucial for successfully adopting and benefiting from AI within the organization.

Ride-hailing platforms process enormous amounts of real-world behavioral data. How do you balance the opportunity to use that data for better personalization and forecasting with the need to preserve trust, privacy, and fairness for both drivers and riders?

The data advantage in ride-hailing is real. Combined with delivery and fintech data, it becomes an extraordinarily rich behavioral dataset. The temptation to over-exploit it is exactly what we refuse to do.

We apply purpose limitation rigorously. We use data collected to improve rides. It doesn’t get repurposed for advertising targeting or sold to third parties. Our users chose inDrive in part because they trust us more than incumbents. That trust, once broken, doesn’t rebuild.

On the driver side, we treat data rights as an economic partnership issue. Drivers are not data sources. They should understand what we collect, how we use it, and – critically – benefit from it. inDrive.Money is a direct example: the same behavioral data that helps us run the marketplace also enables financial services that drivers need and cannot access from traditional banks. That value exchange has to be bidirectional, transparent, and fair.

For forecasting and demand prediction, we prefer aggregate patterns over individual tracking wherever possible. You don’t need to know where one specific person travels every day; you need to know that demand in a given zone increases 30 percent on Friday evenings.

We operate in countries with very different privacy frameworks – from Brazil’s LGPD to markets with minimal data protection laws. Our approach is to hold ourselves to the higher standard regardless of what local law permits. 

The super app model has been highly successful in parts of Asia, but it is harder to replicate across fragmented global markets. What has to be true, from a technology and AI standpoint, for a super app to work across dozens of countries rather than just one tightly integrated ecosystem?

The super app model, which became popular in Asia, worked within relatively homogeneous regulatory and infrastructure environments, with deep integration across payments, social, and commerce that had few strong  independent alternatives. Replicating that globally requires a fundamentally different approach, and we think our model is better suited to fragmented markets.

The foundation has to be global-by-default, local-by-design. We expose shared platform services — identity, wallet, notifications, analytics, maps, support — as stable rails that partners can plug into quickly. Each service is independently deployable and locally configurable, so new markets can be launched through configuration rather than new code. You cannot ship a monolithic product and expect it to resonate everywhere. 

This modular approach allows each product – rides, delivery, grocery, fintech – to adapt to each market’s specific needs while operating on a shared platform.Also, a unified identity and data layer is essential. The entire value proposition of a super app is that using one service improves the others. That requires a single user data graph across verticals. Building that without creating a privacy problem is the hardest technical challenge in the whole endeavour.

Second, the relevance engine has to work at the level of the individual, not the market. What we call a “segment of one” – using data, analytics, and ML to understand what matters to a specific customer in a specific context – is what makes a super app feel useful rather than cluttered. If you have ten services and the app shows you all ten with equal prominence, you have created an app with a bad UX, not a super app. 

Third, you need local partnerships over a build-everything approach. We invested in Krave Mart in Pakistan for grocery, partnered with Fingular and Ammana in Indonesia for financial services. The technology platform is global; the service delivery is local. AI helps by making these integrations seamless to the end user.

Fourth, you need a frequency anchor. This is why grocery matters so much to our strategy. Ride-hailing might be weekly. Grocery is daily or near-daily. 

Lastly, the operational model has to be able to absorb market-by-market variability without losing coherence. Our Zero-Code platform which powers over 400 production screens visited more than 300 million times allows us to launch new screens, run experiments, and adapt to local requirements without full app redeployments. That kind of flexibility, combined with a decentralised multi-region infrastructure, is what lets a platform function coherently across markets, without either forcing uniformity or accepting fragmentation.

Looking ahead three to five years, where do you think AI will create the biggest competitive separation in mobility platforms: demand prediction, trust and safety, autonomous operations, support automation, driver economics, or entirely new services that don’t exist yet?

AI will touch all of these, but the degree of separation will vary.

Within three years, every serious mobility platform will likely have competent demand prediction. Safety and trust features will be table stakes. Support is rapidly becoming automated as LLMs mature. Autonomous operations will matter eventually, but full autonomy globally (outside of well developed markets like the US) is unlikely to materially impact frontier markets for at least another decade.

 A major area of differentiation across the industry, however, is probably marked by entirely new services that don’t yet exist. The combination of real-time location data, behavioural data, payment data, and local market intelligence creates the foundation for services we haven’t conceived of in areas such as hyperlocal commerce, healthcare or predictive logistics. The platform with the richest data foundation and the organizational agility to test and scale new verticals rapidly will have a compounding advantage.

Agentic AI is where the longest-term separation will open up. As agentic workflows mature, handling onboarding, fraud monitoring, financial operations, and personalised coaching, platforms with the right data foundations may enable faster experimentation and scaling.

AI does not create competitive advantage by itself. It creates advantage when combined with unique data, unique market position, and the operational discipline to execute. inDrive’s position – the world’s second most-downloaded ride-hailing app, with dominant positions in frontier markets, over 400 million downloads, and a brand built on fairness – is the foundation. AI is the amplifier. Without the foundation, the amplifier has nothing to amplify. 

Thank you for the great interview, readers who wish to learn more should visit inDrive.