India Approves 12 New Electronics Manufacturing Projects, Launches Semicon 2.0 Portal

The Indian government has approved 12 new projects under the ₹40,000 crore Electronics Component Manufacturing Scheme (ECMS), taking the total number of approved projects under the scheme to 118.

The newly cleared projects are expected to generate production worth ₹39,045 crore and create 7,127 direct jobs.

Key Highlights of the New ECMS Approvals

• 12 new projects approved under the Electronics Component Manufacturing Scheme (ECMS).
• Total approved projects rise to 118.
• Expected production value: ₹39,045 crore.
• Expected direct employment: 7,127 jobs.

States Covered by the Projects

According to the Ministry of Electronics and Information Technology (MeitY), the projects are spread across:

• Gujarat
• Karnataka
• Madhya Pradesh
• Maharashtra
• Punjab
• Tamil Nadu
• Uttar Pradesh

Components to be Manufactured

• Copper foil
• Cathode active materials
• Speciality ceramics
• Multilayer printed circuit boards (PCBs)
• Relays
• Heat sinks

Government Launches ISM 2.0 Portal

Alongside the approvals, Union Electronics and IT Minister Ashwini Vaishnaw launched the application portal for India Semiconductor Mission (ISM) 2.0, also known as Semicon 2.0.

The programme has a fiscal outlay of ₹1.27 lakh crore and aims to strengthen India's semiconductor ecosystem through six strategic pillars, including chip design, equipment and materials, fabrication facilities, packaging, research & development, and talent development.

Applications Invited Under ISM 2.0

• Semiconductor equipment and materials units
• New semiconductor fabrication plants (fabs)
• Semiconductor assembly, testing, marking and packaging (ATMP) facilities
• Outsourced semiconductor assembly and testing (OSAT) operations

Focus on Serious Investors

Vaishnaw said the government will consider only fully complete applications under ISM 2.0, ensuring participation from serious investors and industry players.

Strengthening India's Electronics Supply Chain

The latest approvals and the launch of ISM 2.0 are part of India's broader strategy to build a stronger domestic electronics and semiconductor ecosystem, reduce import dependence, and support long-term growth in electronics manufacturing.

India’s Financial Sector Faces a New Cyber Threat: I4C Warns of AI-Powered Attacks on Banks and Fintechs

India’s cybercrime and cybersecurity authorities have issued one of their strongest warnings yet to the banking and financial services sector, cautioning that cybercriminals are increasingly using artificial intelligence to automate attacks, compromise systems at machine speed, and execute unauthorised fund transfers worth crores of rupees.

The alert, issued jointly by the Indian Cyber Crime Coordination Centre (I4C) and CERT-In, comes amid a series of cyber incidents affecting banks, non-banking financial companies (NBFCs), fintech firms, payment aggregators and digital lending platforms. Authorities say the attacks are financially motivated and are being powered by AI agents capable of identifying vulnerabilities, launching attacks and exploiting payment systems far faster than traditional cybercriminal operations.

AI Is Changing the Economics of Cybercrime

According to the advisory, cybercriminals are leveraging AI agents and "agentic AI" frameworks to automate attack chains that previously required significant human effort. These systems can rapidly identify weaknesses, generate attack scripts, adapt to changing environments and execute fraudulent transactions at machine speed.

The National Cybercrime Threat Analysis Unit (NCTAU), operating under I4C, noted that several cases have already involved multi-crore unauthorised transactions through automated fund disbursement systems and payment APIs.

Unlike conventional cyberattacks, AI-enabled attacks can significantly reduce the time between system compromise and financial theft, limiting the window available for institutions to detect and stop fraudulent activity.

How the Attacks Work

The advisory outlines a pattern that has emerged across multiple incidents.

Attackers first gain entry by exploiting unpatched software, misconfigured internet-facing servers, vulnerable IT infrastructure, or even customer-facing complaint and support systems. Once inside, they target automated payment infrastructure, particularly application programming interfaces (APIs) used for fund transfers, loan disbursements and settlement functions.

Authorities say the attack chain generally follows four stages:

• Compromise vulnerable systems through software flaws or configuration weaknesses.
• Gain access to payment and fund disbursement APIs.
• Transfer money into criminal "mule" accounts across multiple banks.
• Delete logs and evidence to hinder investigation and recovery efforts.

The stolen funds are often moved rapidly through IMPS and NEFT channels, making recovery increasingly difficult.

The Emergence of “Crafty Falcon”

CERT-In's Computer Security Incident Response Team for Finance (CSIRT-Fin) has assigned the designation CRAFTY FALCON to an AI-assisted threat actor believed to be responsible for the ongoing campaign. Authorities describe the actor as capable of surveying targets using machine intelligence and exploiting victims' own payment infrastructure against them.

CERT-In's investigation found evidence that the campaign is active and escalating, with continued reports of successful attacks even against organisations that had previously received warnings and undertaken remediation efforts. Some victims were reportedly re-targeted after incomplete remediation measures, while attacks were often timed to coincide with weekends, holidays and other periods of lower monitoring activity.

AI Tools Being Used by Attackers

CERT-In's analysis found that threat actors are using publicly available AI-based offensive security tools to accelerate attacks. The advisory specifically identified:

• ARTEX family of large language model-based offensive tools
• PentAGI autonomous multi-agent penetration testing system
• Cairn attack search engine
• CyberStrikeAI framework

According to CERT-In, these tools can autonomously execute attack chains, generate customised attack scripts and adapt exploit techniques based on target responses.

Investigators also discovered that attackers have:

• Targeted cloud infrastructure and serverless services.
• Exploited shared credentials and access tokens.
• Reverse-engineered application code to build customised exploits.
• Conducted small-value test transactions before launching larger thefts.
• Bypassed IP allow-listing protections using third-party infrastructure.

Why APIs Have Become the Primary Battleground

A recurring theme in recent regulatory and cybersecurity warnings is the vulnerability of APIs that connect banks with fintech companies and NBFCs.

The Reserve Bank of India (RBI) has recently intensified scrutiny of API security, asking banks to demonstrate compliance with cybersecurity requirements and assess weaknesses in their API ecosystems.

Reuters reported that the RBI has expressed concern over AI-driven attacks on financial infrastructure and sought details about institutions' preparedness for AI-related risks.

Regulators are particularly concerned because APIs serve as critical communication links between banks, fintech platforms and lending institutions. Any weakness in these connections could potentially enable attackers to manipulate payment instructions or move funds fraudulently.

Recent Incidents Raise Alarm

The warnings come amid several high-profile incidents across India's financial ecosystem.

Reuters reported that data belonging to approximately 3,900 customers was leaked from State Bank of India (SBI), the country's largest lender.

Separately, two Mumbai-based NBFCs reportedly suffered over 700 unauthorised transfers worth roughly $2 million after attackers allegedly compromised an API link used for loan disbursal instructions.

These incidents have reinforced concerns that attackers increasingly view smaller lenders, fintech firms and third-party vendors as softer entry points into the financial ecosystem.

What Financial Institutions Have Been Told to Do

The advisory directs banks, NBFCs, fintechs, payment aggregators and payment gateways to urgently implement protections outlined in CERT-In's critical advisories issued in October 2026.

Authorities also recommended several additional safeguards:

• Maintain a complete inventory of payment-related APIs.
• Disable obsolete, unused and test interfaces.
• Introduce daily and per-transaction limits.
• Verify beneficiary names before transfers.
• Monitor unusual transaction velocity and volumes.
• Improve coordination between security operations, transaction monitoring teams and IT departments.
• Implement continuous monitoring and heightened vigilance.

Financial institutions have additionally been instructed to:

• Report cyber incidents to CERT-In within six hours of detection.
• Report incidents to the RBI through the DAKSH portal.
• Coordinate with I4C for rapid freezing of fraudulent transactions where required.

A Wider Regulatory Push on AI Risk

The warning forms part of a broader regulatory effort to address AI-related risks in the financial system.

Earlier this year, the RBI proposed new guidelines requiring banks to establish board-approved risk management frameworks covering AI and machine learning models, including independent validation requirements and stronger governance controls. For generative AI systems that interact with customers, the RBI proposed additional cybersecurity safeguards and human oversight mechanisms.

At the same time, regulators in the United States, United Kingdom and other jurisdictions are stepping up efforts to manage AI-related risks as AI capabilities become increasingly integrated into both financial services and cybercrime operations.

The Bigger Picture

The I4C and CERT-In advisories signal a significant shift in India's cybersecurity landscape. Financial institutions have long faced cyber threats, but the emergence of AI-assisted attack frameworks is changing both the scale and speed of attacks.

Rather than simply helping hackers write malicious code, AI is increasingly being used to automate reconnaissance, adapt attacks in real time, exploit APIs, evade detection and accelerate money movement through financial systems. Authorities now view these capabilities as an immediate operational risk rather than a future concern.

For India's banks, fintechs and NBFCs, the message from regulators is clear: AI-powered cyberattacks are no longer theoretical. They are active, financially motivated and already being used in attempts to compromise financial infrastructure and move funds at machine speed.

Base Launches Upgrade to Make Transactions Faster and More Reliable

Introducing Base Denim

Base’s fourth upgrade, Denim, is now live on mainnet. Denim brings native 200ms blocks to Base that replaces flashblocks: five complete canonical blocks every second. Contracts can now read time to the millisecond onchain, and B20 gets safer transfers and simpler compliance controls.

Base’s north star is to bring the world onchain, starting with trading, financing, and payments. Those use cases need a chain that updates state often and lets builders reason about time precisely. Denim changes the block cadence of Base itself: instead of one block every two seconds with a pending-state preview in between, Base now produces a full canonical block every 200 milliseconds.

What’s in Denim?

Denim delivers three changes:

• Native 200ms blocks: five complete canonical blocks per second, replacing Flashblocks
• BaseTime: millisecond-resolution time for contracts and RPC clients
• B20 improvements: safer transfers and reusable compliance policies

Native 200ms blocks

Before Denim, Base produced one canonical block every two seconds. Flashblocks filled the gap by streaming incremental pending-state updates for the block being built, so apps could show a preview of state before the block landed.

Base now produces five canonical blocks per second, and each one is a real block, not a preview. Once your transaction is in a 200ms block, it is in. There are no preconfirmations that can be walked back, there is no pending state to reconcile, and there is no separate stream to subscribe to. Block production is simpler, more consistent, and more reliable.

Blocks cannot skip slots. Each block’s full timestamp is exactly 200ms after its parent’s, and the protocol validates that progression, so the cadence is a property of the chain rather than of the sequencer’s wall clock.

Why native blocks beat Flashblocks

No preconfirmation reorgs. A Flashblock was a preview of a block still being built, and a preview can be dropped from the block that finally lands. Apps that showed Flashblock state had to be ready to walk it back. A 200ms block is not a preview of anything: it is the canonical block, with the same guarantees as every other block on Base. Reorgs caused by Flashblocks are gone, along with the separate Flashblocks stream that could degrade while block production continues.

Every standard RPC just works. Sub-second state no longer lives behind a special subscription or a "pending" tag with Flashblocks-aware semantics. eth_subscribe("newHeads"), eth_getLogs, eth_call, eth_getTransactionReceipt and every other standard JSON-RPC method return 200ms state out of the box, so viem, ethers, Foundry and existing indexers work without a Flashblocks client or a reconciliation layer.

Faster canonical inclusion. Before Denim, a transaction waited up to two seconds for the next canonical block. Now the next canonical block is never more than 200ms away. Payments confirm in the block, trades settle in the block, and the app reads the receipt from the block, with no preconfirmed state to reconcile later.

Finer-grained time for DeFi. Five blocks per second give lending, trading and rewards protocols five opportunities per second to react: liquidations can execute in the first block after a price update rather than the next two-second block, and oracles and keepers can act on a 200ms cadence. With BaseTime, contracts also get the millisecond clock to match, so interest accrual, reward streaming and yield calculations can run at 200ms resolution instead of once per second.

Flashblocks is retired

Denim replaces Flashblocks. Base no longer produces Flashblocks streams, and the "pending" block tag no longer returns a preconfirmed state. Applications that consumed Flashblocks need to move to canonical block and RPC streams:

Before Denim	After Denim
eth_subscribe("newFlashblocks")	eth_subscribe("newHeads")
eth_subscribe("pendingLogs")	eth_subscribe("logs")
eth_subscribe("newFlashblockTransactions")	eth_subscribe("newHeads"), then fetch each block's transactions
eth_getBalance, eth_call, eth_getBlockByNumber with "pending"	The same methods against the latest canonical block

The full mapping is in Migrate From Flashblocks.

block.number advances ten times faster

Because Base now produces ten times as many blocks per second, any contract or offchain system that treats a block count as a duration will see that duration shrink to one tenth of its intended length. block.timestamp is unaffected and still advances in whole seconds.

Review any logic of this shape:

• Timelocks, cooldowns and exit delays written as block.number - start >= N
• Vesting, emission and difficulty schedules measured in blocks
• Per-block rate limits or caps that reset when block.number changes
• Deadlines set as expirationBlock = block.number + N
• Governance voting delay and period in blocks, including ERC20Votes with the default block-number clock()
• Fixed-cardinality TWAP oracles, which now cover roughly half as much wall-clock history before observe() reverts

Where you can redeploy or upgrade, replace block-count durations with block.timestamp comparisons. Where a block count is governance-tunable, divide it by ten. The 200ms Native Blocks spec has the full table.

BaseTime

With BaseTime, your app can measure elapsed time and check deadlines with millisecond precision, whether you’re running an auction, expiring an order or calculating rewards.

Ethereum block headers store timestamps in whole seconds, and Denim keeps that unchanged: block.timestamp in the EVM and the timestamp field in JSON-RPC responses are still seconds. With five blocks per second, five consecutive blocks share the same block.timestamp. A contract that accrues interest, streams rewards or expires orders by comparing timestamps sees zero elapsed time between four of every five blocks, then a full second jump.

BaseTime supplies the missing milliseconds, so time onchain moves with every block instead of stepping once per second.

Every Denim block carries a BaseTime metadata update at transaction index 1, right after the L1 info deposit, that writes the block’s sub-second part (0, 200, 400, 600 or 800) to the BaseTime predeploy at 0x4200000000000000000000000000000000000030. Because the deposit executes before user transactions, any contract in the block can read the block’s full millisecond timestamp.

Code Example

Use case: a contract that needs sub-second time, such as an auction or order-expiry check:

interface IBaseTime {
    function timestampMillisPart() external view returns (uint16); // 0, 200, 400, 600 or 800
    function timestampMs() external view returns (uint64);         // full Unix time in milliseconds
}

IBaseTime constant BASE_TIME =
    IBaseTime(0x4200000000000000000000000000000000000030);

function isExpired(uint64 expiresAtMs) internal view returns (bool) {
    return BASE_TIME.timestampMs() >= expiresAtMs;
}

Millisecond timestamps over RPC

Tooling gets the same precision without calling the predeploy. Block and header responses (eth_getBlockByHash, eth_getBlockByNumber, eth_getHeaderByHash, eth_getHeaderByNumber, eth_subscribe("newHeads")) add an optional timestampMs field, and mined transactions, logs and receipt logs add an optional blockTimestampMs.

For example, a block at 42.200 seconds returns:

{
  "timestamp": "0x2a",
  "timestampMs": "0xa4d8"
}

These values come from the authenticated BaseTime metadata in each block, not from an estimate based on the seconds field. The existing timestamp field is unchanged, so clients that ignore the new fields keep working. Pre-Denim blocks omit the new fields.

B20 improvements

Denim makes B20 tokens safer for users and gives issuers stronger and simpler compliance controls. These changes help prevent accidental sends to the token’s own address, enforce issuer transfer rules consistently, and reuse compliance lists. Existing integrations keep working unless noted below.

PolicyRegistry gains one view, invertedPolicyId. The token interface gains no new functions, events or errors.

Reusable compliance lists

Cobalt lets issuers combine policies with AND and OR operators. Denim adds NOT. Any policy ID can be inverted by setting a reserved bit, and isAuthorized returns the opposite of the base policy’s result. Members live on the base policy and are shared, not copied, so an issuer can use one address list to mean “only these addresses” in one scope and “exclude these addresses” in another, with no second list to keep in sync.

Example breakdown

• A compliance provider maintains one sanctioned allowlist whose members are sanctioned addresses.
• The issuer builds a composite transfer policy, KYC AND NOT sanctioned, passing invertedPolicyId(sanctioned) as the second child.
• A transfer to Alex, who is KYC-verified and not on the sanctions list, settles. If the provider adds Alex to the sanctions list, the next transfer to him fails. Nothing else changes, because the inverse reads the same list.

Stronger transfer controls for regulated assets

Issuers of restricted securities often require every transfer to be initiated by an approved party, such as a transfer agent. B20’s TRANSFER_EXECUTOR_POLICY is the allowlist for that pattern, but before Denim it only applied to transferFrom calls made by someone other than the holder. A holder could bypass it by calling transfer directly.

After Denim, TRANSFER_EXECUTOR_POLICY is checked on msg.sender for every transfer path, matching how the sender and receiver policies already work. B20 tokens launched with TRANSFER_EXECUTOR_POLICY set will automatically inherit the new behaviour noted above. Tokens that never set an executor policy keep the always-allow default and see no change.

Example breakdown

• A fund’s token sets TRANSFER_EXECUTOR_POLICY to an allowlist containing only its transfer agent.
• The agent calls transferFrom(alice, bob, 500) after Alice has approved it. The transfer succeeds.
• Alice calls transfer(bob, 500) directly. Before Denim this succeeded; after Denim it reverts with PolicyForbids, because Alice is not an allowlisted initiator.

Note: The issuer chooses whether to set an executor policy and who is on it; Base does not decide who may initiate transfers.

Protection against lost funds

Users sometimes paste the token’s own address as the recipient. A B20 token is a precompile with no holder key, so tokens credited to it were stuck unless the issuer seized them back.

After Denim, any transfer, mint or seizure whose recipient is the token’s own address reverts with the existing InvalidReceiver error, the same error wallets already handle for address(0).

Example breakdown

• Alex copies the wrong address from an explorer and tries to send 500 tokens to the token contract itself.
• The transfer reverts with InvalidReceiver. Alex’s balance is unchanged, and the wallet shows the same error it shows for a send to the zero address.
• Self-sends, sends to other B20 tokens, approvals and burns are unaffected. An issuer can still recover a balance that reached the token address before Denim with seizeWithMemo(address(token), treasury, amount, memo) if they have opted into seize functionality for their token.

For technical details and migration steps, see the Denim B20 changelog:

• Token Receiver
• Transfer Executor Enforcement
• NOT / Invert Policies

How Denim impacts you

Users

No action needed. Transactions land in canonical blocks that arrive every 200ms, and mistaken sends to a B20 token’s own address now fail instead of locking funds.

App and wallet developers

If you consume Flashblocks or use the "pending" block tag, migrate to canonical block subscriptions and the latest block: see Migrate From Flashblocks.

If you need sub-second time, read timestampMs from block responses or call the BaseTime predeploy.

Contract developers

Audit any logic that converts block counts to time. block.number now advances ten times faster in wall-clock time; block.timestamp is unchanged.

See Block-Number-Based Contract Logic.

Trading teams and market infrastructure

You now observe a canonical state every 200ms, the next block is never more than 200ms away, and blocks, transactions and logs carry millisecond timestamps.

There is no pending-state stream to reconcile against canonical blocks and no preconfirmation that can be dropped from the final block.

DeFi protocols

Lending, DEX and rewards protocols get five blocks per second to liquidate, rebalance and update, and can read BaseTime.timestampMs() to accrue interest, stream rewards and expire orders at 200ms resolution instead of once per 2 seconds.

Review block-count timing assumptions before relying on the new cadence.

RPC providers, indexers and explorers

Expect ten times the block count per unit time, and the new optional timestampMs and blockTimestampMs fields on block, transaction, log and receipt responses.

Flashblocks streams have stopped.

Bridges and proof flows that read historical block hashes or beacon roots retain the same number of values, but that history now covers one tenth of the elapsed time.

Issuers

If your token sets a restrictive TRANSFER_EXECUTOR_POLICY, add holders (or a policy covering them) to the executor allowlist if you want holder-initiated transfers to keep working.

Treat the token’s own address as an invalid recipient in your tooling.

Use invertedPolicyId to replace mirrored allow and block lists.

If there's something we can do better, we want to hear it. Reach us on X, Discord, or GitHub.

Disclaimer

Base is open-source, permissionless blockchain infrastructure. Base provides neutral protocol infrastructure only and does not control the persons, applications, or assets that use it.

B20 tokens are deployed, configured, and administered solely by their respective issuers; issuer-controlled features such as minting, burning, freezing, and seizure are exercised at the issuer's sole discretion.

References to third-party issuers or assets are informational and not an endorsement.

Except with respect to assets that Coinbase or its affiliates expressly issue (which are offered only in eligible jurisdictions and governed by their own terms and disclosures), Coinbase, including Base, is not the issuer, investment adviser, broker, dealer, underwriter, promoter, distributor, or transfer agent for any B20 token or transaction, and nothing here is investment advice or a recommendation to buy or sell any digital asset.

Forward-looking statements about future upgrades, features, or performance are subject to change and are not commitments to deliver.

Illustrative examples are hypothetical and are provided solely to demonstrate potential use cases for new functionality.

They are not exhaustive and do not constitute a recommendation, solicitation, or representation that any particular use case, strategy, application, asset or outcome will be available, suitable, profitable or successful.

LTM, ServiceNow Team Up to Bring Agentic AI Into the Enterprise Mainstream

• Combines the ServiceNow AI Platform with LTM’s domain and technology expertise to help enterprises deploy governed agentic AI at scale.
• Strengthens joint go-to-market efforts for more than 700 shared customers, using LTM’s own transformation as a proven enterprise blueprint.

ServiceNow (NYSE: NOW), the Super Intelligence Control Tower for business reinvention, and LTM, the Business Creativity partner to the world's largest enterprises, today announced a planned expansion of their partnership to scale agentic AI and accelerate joint go-to-market initiatives for customers. The companies will bring together the ServiceNow AI Platform and LTM’s domain, engineering, and transformation expertise to help enterprises move agentic AI programs from isolated use cases to governed, enterprise-wide adoption and measurable business outcomes.

As an Elite ServiceNow Partner serving more than 700 joint customers, LTM will use its own enterprise transformation as a ‘client-zero’ blueprint. LTM has deployed 1,500 ServiceNow AI Agents across its operations, creating a digital workforce that works alongside employees, while ServiceNow Super Intelligence Control Tower provides a single system of action for AI inventory and risk oversight, with LTM expecting up to an 80% improvement in AI asset management and efficiency. LTM’s own ServiceNow deployment will inform joint solutions and go-to-market programs designed to help customers adopt, govern, and scale agentic AI with greater speed and confidence.

The ServiceNow AI Platform is already helping LTM achieve measurable value across cybersecurity, HR, IT, and project delivery. ServiceNow solutions are streamlining security operations, reducing IT ticket volumes, and enabling up to 87% faster senior management review cycles.

Our expanded partnership with ServiceNow will help enterprises move agentic AI from experimentation to meaningful business impact,” said Krishnan Iyer, Chief Growth Officer, LTM. By combining the ServiceNow Platform with LTM’s domain, engineering, and transformation expertise, we will jointly develop solutions and go-to-market programs that help customers deploy agentic AI with greater speed and confidence.

LTM is showing what an AI-powered enterprise looks like: a new workforce of AI agents working alongside their people, delivering faster threat responses, fewer IT tickets, and higher HR productivity. But every agent is a new identity with enterprise access, and most companies can't say where their agents are, what they're doing, or who's accountable, said Kulmeet Bawa, GVP & Managing Director, ServiceNow India & SAARC. With the ServiceNow Super Intelligence Control Tower, LTM has visibility and control, so their people stay focused on the judgment calls that matter. Now more than 700 joint customers get to learn from a partner who's already done it.

About ServiceNow

ServiceNow (NYSE: NOW) is the Super Intelligence Control Tower for business reinvention. The ServiceNow platform integrates with any model, any cloud, and any data source to orchestrate, govern, and secure work across the agentic enterprise. ServiceNow gives customers the enterprise context and control to build and scale confidently. With more than 100 billion workflows running on the platform each year, ServiceNow helps organizations turn fragmented operations into coordinated, autonomous work for IT, CRM, Security, Employee Experience, and more. Learn how ServiceNow puts AI to work for people at www.servicenow.com.

EXL Acquires Aimpoint Digital to Accelerate Enterprise AI Adoption

• Combines Aimpoint Digital’s forward-deployed AI engineering and platform expertise with EXL’s deep industry knowledge, proprip. etary agentic AI capabilities, and operational scale to transform mission-critical enterprise workflows
• Deepens expertise across leading AI platforms including Anthropic, Databricks, and Snowflake, accelerating the journey from AI strategy to production and measurable business outcomes
• Advances EXL’s strategy to deliver end-to-end enterprise AI transformation, connecting AI development, engineering, deployment, evaluation, and managed operations

EXL [NASDAQ: EXLS], a global data and AI company, today announced it has acquired Aimpoint Digital, a data and AI consulting and platform engineering firm known for building enterprise data and AI platforms with deep expertise in market-leading partners including Anthropic, Databricks, and Snowflake. The acquisition strengthens EXL’s ability to support clients across the full AI transformation lifecycle and deepens EXL’s existing relationships with key technology partners. Financial terms of the transaction were not disclosed.

Enterprises are investing heavily in AI, yet many organizations continue to struggle to move AI initiatives from pilot to production-scale value. Aimpoint Digital has built a reputation for moving client workloads onto leading data and AI platforms with speed. By bringing Aimpoint Digital into EXL, the two companies will scale that strength across more workflows and functions, extending AI’s business impact across the enterprise and broadening EXL’s offering for enterprise-wide transformation.

“Clients require a partner who can take them from AI ambition to impact at enterprise scale,” said Rohit Kapoor, chairman and chief executive officer, EXL. “Aimpoint Digital’s forward-deployed strategists and engineers bring the hands-on expertise to turn AI strategy into production reality on the platforms our clients trust most. By bringing their advisory and engineering talent together with EXL’s data foundations, industry expertise, agentic AI solutions, and operational scale, we can reimagine workflows and give clients a single, accountable partner for the entire journey — from strategy and architecture through deployment and managed AI operations.”

“Joining EXL lets us do more breakthrough work on a much larger scale,” said Ben Yopp, chief executive officer and cofounder, Aimpoint Digital. “We bring deep AI strategy and engineering talent and EXL brings industry expertise, global reach and the ability to run AI in operations. Together, we can take clients’ most important AI initiatives into production and keep them performing at the highest levels.”

EXL and Aimpoint Digital will provide clients with greater continuity from the first strategy conversation through architecture, engineering, production deployment, and managed operations. This connected approach is designed to reduce handoffs, establish clearer accountability, and accelerate the path to measurable outcomes.

In a marketplace where demand for strategic data and AI engagements outpaces available talent, the combination adds approximately 250 experienced AI engineers, platform architects, analytics consultants, decision scientists, and AI strategists to EXL's data and AI capabilities. This expands EXL’s forward-deployed talent base, puts senior AI expertise closer to client teams, and adds capacity for complex, multi-year transformations.

Aimpoint Digital also brings deep expertise working with strategic partners, expanding EXL's partner ecosystem footprint and deepening expertise on partners such as Anthropic, Databricks, and Snowflake. This will help clients reimagine core workflows while building on the platforms they trust and helping them get to production sooner.

The acquisition builds on EXL’s recent acquisition of iMerit, a global leader in AI model training, evaluation and reinforcement learning and reinforcement learning. Together, iMerit and Aimpoint Digital extend EXL’s ability to support clients from strategy and architecture through engineering, deployment, and managed AI operations — reflecting EXL’s disciplined strategy of extending its data and AI capabilities through investments in innovation, acquisitions, and talent.

About EXL

EXL (NASDAQ: EXLS) is a global data and AI company that offers services and solutions to reinvent client business models, drive better outcomes and unlock growth with speed. EXL propels enterprises to go beyond AI ambition to impact by combining the power of data, AI, and deep industry context with trusted execution. Our clients include the world's leading corporations across insurance, healthcare, banking and capital markets, retail, communications and media, and energy and infrastructure, among others. EXL was founded in 1999 with the core values of innovation, collaboration, excellence, integrity and respect. We are headquartered in New York and have over 74,000 employees spanning six continents. For more information, visit https://www.exlservice.com.