For millions of immigrants, sending money is only one step in a larger recurring job: making sure parents' utilities are paid, insurance renews, tuition is covered, loan payments are made, healthcare expenses are handled, and family members have what they need each month.
The transfer itself has become increasingly easy. The responsibility has not.
AgentPay is building an AI financial agent that manages those recurring responsibilities for immigrants supporting family back home. We are starting with the U.S. to India corridor.
Our core belief is simple: the unit of the product should not be the transfer. It should be the obligation.
01The problem
A remittance product begins when a user decides to send money and ends when the money arrives.
The user's real workflow begins earlier and ends later.
Someone supporting family abroad may need to remember that a parent's insurance renews next month, a sibling's tuition is due next week, an EMI is charged on a fixed date, a utility bill changes each month, and an unexpected medical expense requires attention today. These obligations have different recipients, amounts, schedules, priorities, and levels of urgency.
Today the sender reconstructs this system manually. The information lives across family WhatsApp messages, bank apps, biller portals, calendars, spreadsheets, emails, and memory. Then the sender chooses a payment product and executes each task individually.
This is not primarily a money-movement problem. It is a coordination and execution problem wrapped around money movement.
Remittance companies have made the last mile of the user's workflow much better. AgentPay is focused on the rest of the workflow.
02The thesis
The dominant model in cross-border consumer finance is transaction-centric:
sender → transfer → recipient
We think a more useful model is obligation-centric:
responsibility → rules → monitoring → execution → exception handling
An immigrant does not fundamentally want to send $500. They want a specific responsibility taken care of.
That distinction matters because obligations persist. A transfer is a discrete event; a responsibility can last for years.
Once software understands the recurring obligation, its normal range, timing, intended recipient, and the circumstances that require human attention, it can do more than make a payment easier. It can take over part of the job.
That is the shift AgentPay is built around: from transaction software to delegated financial responsibility.
03Why now
Three changes are happening at the same time.
First, cross-border payments are becoming easier and more programmable. India alone was estimated by the World Bank to receive roughly $129 billion in remittances in 2024.1 The market is enormous, established, and increasingly digital.
Second, destination-side payment infrastructure is improving. India has broad digital bill-pay and bank-transfer infrastructure, reducing the need to invent a new consumer payment rail from scratch.
Third, AI systems are moving from answering questions to taking actions. The important product transition is not simply better financial advice. It is software that can complete bounded financial tasks under explicit user authority.
The infrastructure pieces are becoming good enough that the new product can be built one layer above the transfer itself.
04The product
AgentPay is an AI financial agent for immigrants who regularly support family in another country.
A user should be able to express a responsibility in normal language, for example:
Take care of my parents' recurring household expenses in India. Keep routine spending within the limits I set and ask me before anything unusual.
AgentPay turns that intent into a persistent financial responsibility. The agent tracks what needs attention, handles routine actions within the user's approved boundaries, and escalates exceptions back to the user.
The product is intentionally designed around constrained authority rather than unrestricted autonomy. The user remains the principal. The agent receives only the authority needed to carry out the responsibility the user has delegated.
At a high level, the experience is:
- Tell AgentPay what you are responsible for
- Define boundaries
- AgentPay monitors the obligation
- Routine actions can be executed within policy
- Unusual actions return to the user
- The completed responsibility is recorded
The goal is not to make people think about stablecoins, wallets, or payment routing. The goal is to make cross-border family responsibilities disappear from the user's mental checklist because the user can trust that they are being handled.
05The initial wedge
AgentPay is starting with Indian immigrants and NRIs in the United States who regularly support family in India.
This corridor has several attractive characteristics: a very large existing remittance market, strong digital financial infrastructure in India, a population familiar with recurring cross-border financial responsibilities, and a broad range of obligations that can be observed and validated quickly.
The initial use cases are deliberately narrow: recurring household and family obligations with clear recipients, predictable patterns, and explicit user-defined limits.
The wedge is not "send money to India with AI." There are already excellent products for sending money.
The wedge is: delegate a responsibility and have the software continuously manage it.
06Why an agent changes the product
Traditional fintech software is mostly request-response. The user opens an app, decides what to do, provides the instructions, and confirms the transaction.
A recurring family obligation is different. The user has already made the high-level decision: this responsibility should be handled every month unless something unusual happens.
Requiring that person to repeatedly recreate the same intent is unnecessary work.
An agent can persist the intent across time. It can recognize that an obligation is recurring, distinguish routine behavior from an exception, and bring the human back into the loop only when the situation requires judgment.
This creates a different user relationship. The software is no longer a tool the user visits when they want to transact. It becomes an ongoing delegate for a defined part of their financial life.
07Why onchain infrastructure is useful
AgentPay is not a crypto product looking for a consumer use case. Onchain infrastructure is useful because an autonomous financial agent needs programmable, auditable authority over money.
Base and modern smart-account infrastructure make it possible to define bounded spending permissions around token, amount, and time period.2 USDC provides a programmable settlement asset.3 The combination creates a clean separation between the user's capital and the agent's limited authority to act.
That matters for a product in which the agent should be able to complete routine transactions without receiving unrestricted access to the user's funds.
The product experience can remain consumer-native while the authorization and settlement layer becomes machine-native.
Specific implementation details, routing logic, compliance architecture, and partner design are intentionally outside the scope of this public memo.
08A different kind of financial graph
Every recurring obligation contains more information than a transfer.
A transfer says that one person sent an amount of money to another person at one moment in time.
An obligation can encode a persistent relationship: who supports whom, which expense recurs, when it is normally due, how much it usually costs, what constitutes an exception, and whether the responsibility is consistently fulfilled.
Over time, successful execution creates a structured history of cross-border household support.
That history could become useful for future financial products. One example is remittance-backed or sender-supported credit, where an established cross-border support relationship may help a local recipient access financing. Base's Ecosystem Fund has independently identified multi-party and remittance-backed credit, including an international sender supporting a local recipient, as an area of interest.4
AgentPay does not need to begin as a lender. The first job is simpler: execute the responsibility reliably. But owning the execution layer may create a foundation for credit, insurance, savings, and other cross-border family financial products later.
09Market
The starting market is already large without inventing a new behavior.
The World Bank estimated that India would receive approximately $129 billion in remittances in 2024, making it the world's largest recipient market.1 These flows already represent people supporting households, education, healthcare, housing, savings, and other needs across borders.
AgentPay is not betting that immigrants will suddenly begin supporting family. That behavior already exists at enormous scale.
The bet is that a meaningful portion of the repeated operational work around that support can move from humans to software.
If that happens, the relevant market is broader than remittance fees. It includes the financial activity attached to the responsibilities themselves and, eventually, the financial products that can be built around long-lived cross-border household relationships.
10Competition
Competition validates the underlying behavior.
Wise, Remitly, Western Union, banks, and emerging products such as Zelle's international expansion compete to move money across borders efficiently.
Abound is much closer to the direction of AgentPay. It serves NRIs and has introduced AI-driven automation around remittances and other financial tasks. Surgepay is building U.S. to India remittance and bill-payment experiences and has publicly discussed agent-initiated workflows.
Destination-side products such as Bharat Connect and WhatsApp increasingly make individual bills easier to discover and pay.
We expect incumbents to continue improving automation.
Our thesis is not that these companies cannot add AI. It is that the durable product layer is the persistent obligation relationship itself.
A transfer company is optimized around moving money. A bill-pay product is optimized around paying a bill. AgentPay is designed around continuously owning the responsibility: understanding what must happen, maintaining the user's boundaries, executing across the appropriate rails, and handling exceptions over time.
The market can support multiple large companies. The question is which company becomes the trusted execution layer for the cross-border household.
11Business model
The near-term business model should follow the value created by taking recurring work off the user's plate, rather than depend on opaque FX spread as the sole source of economics.
Potential revenue can come from consumer software, transaction economics, and later financial products built around the relationship.
We are intentionally not locking the company into a single monetization path before observing how early users behave. The first objective is to earn the right to manage recurring financial activity by becoming reliable enough that users delegate real responsibilities.
Detailed pricing assumptions and unit economics are intentionally omitted from this public memo while the product is early.
12Distribution
The initial customer is not "everyone who sends remittances."
It is the person who has become the remote financial operator for a household back home: the family member who receives the messages, remembers the deadlines, sends the payments, keeps track of recurring expenses, and gets called when something breaks.
That user has a recurring problem rather than an occasional transaction.
The first distribution goal is therefore to find concentrated communities of U.S.-based Indians with ongoing family financial responsibilities, learn which obligations create the highest repeated burden, and build around those workflows.
The long-term distribution advantage should come from the product becoming embedded in recurring responsibilities. A product used for a one-time transfer has to win the customer again on the next transfer. A product entrusted with an ongoing responsibility has the opportunity to become part of the household's financial operating system.
Specific acquisition channels and partnership strategy are intentionally omitted from this public memo.
13Trust, control, and safety
An agent that can move money has a much higher trust requirement than an agent that can draft an email.
The product therefore has to make delegation legible. Users need to understand what the agent is allowed to do, what it is not allowed to do, when it will ask for approval, and what happened after an action was taken.
The core design principle is bounded delegation: routine execution inside clear limits, human judgment outside them.
The goal is not maximum autonomy. The goal is the maximum amount of useful autonomy that a user can understand and trust.
The implementation of risk controls, exception handling, fraud prevention, compliance, and recovery is intentionally not disclosed in this memo.
14Progress
AgentPay began in August 2026.
The initial product thesis and U.S. to India wedge have been defined, the public product site is live, and a prototype has been built around recurring financial obligations and constrained agent execution.
The immediate product milestone is moving from prototype behavior to live end-to-end execution for a small set of recurring obligations with early users.
15Why this can become a large company
The wedge is intentionally narrow. The underlying relationship is not.
A household supported across borders may have years of recurring payments, multiple family members, multiple categories of spend, changing financial needs, and eventually demand for savings, insurance, credit, investing, and other financial products.
The company that reliably executes the recurring obligations earns something more valuable than a single transaction: persistent context and trust around the cross-border household's financial life.
The long-term ambition is for AgentPay to become the financial operating layer between a migrant and the household they support.
The path begins with one job that is easy to understand:
Take care of home.
16Risks
The company has several real risks.
- Trust
- Consumers may be slow to delegate financial execution to software, especially for high-stakes or unusual transactions.
- Incumbents
- Remittance providers, banks, wallets, and large payment companies can add increasingly capable automation.
- Regulation
- Cross-border payments, money transmission, identity, consumer protection, and financial services require careful jurisdiction-specific implementation and regulated partners where applicable.
- Execution complexity
- A product that promises to handle a responsibility must work across fragmented billers, institutions, payment methods, and exception cases.
- Agent reliability
- Probabilistic reasoning cannot be allowed to translate directly into unbounded financial authority.
These are not side issues. Solving them well is part of the product.
This memo intentionally does not disclose AgentPay's internal approaches to these problems.
17What we believe
We believe cross-border family finance will move through three stages.
- Stage 1Digitizing the transfer.
- Stage 2Making the transfer faster, cheaper, and increasingly invisible.
- Stage 3Delegating the responsibility itself.
In that world, a user should not need to remember every recurring payment, choose a rail, enter the same details, and coordinate the same family workflow every month. The user expresses the responsibility and the boundaries. Software handles the repetitive execution and brings the human back when judgment is required.
Remittance is a transaction.
Supporting a family is an ongoing job.
AgentPay is built for the job.
—Sources
- World Bank, 2024 remittance estimates. blogs.worldbank.org ↗
- Coinbase Developer Platform, Spend Permissions. docs.cdp.coinbase.com ↗
- Base, Payments. base.org/payments ↗
- Base Ecosystem Fund, Request for Builders: multi-party and remittance-backed credit. blog.base.org ↗