For more than fifteen years, every fintech company that wanted to move money in the United States has had to partner with a sponsor bank. That structure is deliberate. It was built for a financial system in which moving money and holding deposits sat inside the same institution, and the regulatory categories reflected that bundling. 

But as software-native financial products emerged, the framework didn’t expand to recognize new categories of providers. Instead, those providers were folded into a banking model that pre-dates the internet.

The PACE Act of 2026 is the first serious legislative attempt to give qualified nonbanks an alternative path to the federal payment rails that doesn’t require routing through a sponsor bank.

For builders of programmable dollar infrastructure, PACE is confirmation that direct rail access is now a recognized federal category that runs in parallel to the sponsor-bank model rather than depending on it.

Access to U.S. payment rails has required every fintech company to work with a bank sponsor. Fintechs that aren't banks themselves partner with sponsor banks holding master accounts at the Federal Reserve. The bank provides access; the fintech extends services to its users.

This is currently the only regulatory pathway available, and it comes with structural constraints. A nonbank provider’s settlement speed, pricing, and product capabilities are all bounded by the parameters of whichever sponsor bank it partners with, and end users see the variation in their fees, settlement times, and product consistency.

The Payments Access and Consumer Efficiency (PACE) Act of 2026, introduced on April 21 by Reps. Young Kim (R-CA) and Sam Liccardo (D-CA), opens a second pathway for qualified nonbank payment providers to access Federal Reserve systems. The sponsor-bank model continues as before, and most providers will continue to use it; PACE simply adds a parallel option for those that meet a higher regulatory bar. The same Fedwire Funds Service, FedNow Service, and FedACH infrastructure that banks use would, under PACE, also be available to qualified nonbanks directly.

The PACE Act comes on the heels of 2025’s GENIUS Act, which established a federal framework for stablecoin issuance and custody. PACE does the same for payment rail access. Because the two bills share definitions and risk standards, a provider operating under GENIUS and PACE can adopt a single, coherent compliance posture rather than relying on a patchwork of policies adapted from legacy finance.

This new posture means that faster, more transparent, and 

 will become available to consumers and businesses.

The PACE Act establishes a new legal category: the “registered covered provider.” To belong to this category, a company must hold:

At least 40 active state money transmitter licenses.

A state depository institution charter OR a state credit union charter.

These requirements act as a “pre-vetting” for eligible companies seeking to register. The OCC evaluates applications according to a set of factors, including financial resources, Bank Secrecy Act compliance, and, critically, whether the applicant demonstrates a benefit to the public through innovation, competition, and broader access to payment services.

Then, once the OCC has granted the license, the Federal Reserve approves or rejects the payments reserve account covering Fedwire, FedNow, and FedACH. The Fed must approve or deny within 120 days, after which approval is granted automatically.

Access Comes With Responsibility and Oversight

Registration is the entry point of regulatory oversight. Once approved, registered covered providers operate under a continuous and demanding set of obligations, including reserves, custody requirements, fair-access mandates, and insolvency protections that, in some respects, exceed what customers receive in other corners of the financial system.

“Registered covered providers” must maintain 1:1 reserves backing all outstanding customer obligations in strictly defined liquid assets: U.S. currency, Fed account balances, short-term Treasuries, overnight repos, government money market funds, and tokenized equivalents. These reserves cannot be rehypothecated. Customer funds held in custody must be segregated and cannot be commingled with the provider’s own assets.

In addition, the OCC retains full examination authority and can enforce requirements under the same statutory authority it uses against insured depository institutions.

The PACE Act also includes an explicit fair access obligation: providers may not deny services or cancel accounts based on a customer’s constitutionally protected beliefs, affiliations, or political views. All access decisions must be individualized, objective, and risk-based.

In insolvency, customer payment obligations rank ahead of all other liabilities except administrative costs, and properly segregated custodial assets sit entirely outside the estate. Arguably, consumers have stronger statutory protections under the provisions of the PACE Act than they do in many other financial contexts.

PACE is not a deregulatory bill. It defines a higher bar than the current sponsor-bank model imposes on most fintechs, and it makes that bar continuous rather than situational. Compliance becomes a property of the institution itself, not a downstream artifact of a banking relationship.

PACE + GENIUS: Deliberate Policy Architecture

The PACE Act sits alongside the GENIUS Act stablecoin framework as part of a broader 2026 rewrite of U.S. payment infrastructure policy. PACE explicitly cross-references GENIUS definitions and risk management standards, establishing a shared regulatory foundation between the two pieces of legislation.

GENIUS established stablecoin issuance and custody as a directly chartered federal activity. PACE does the same for payment rail access. Together, they create a coherent federal category for programmable dollar infrastructure that sits alongside the bank category rather than within it. Congress is responding to calls for a new class of institution to operate in parallel to existing ones, replacing the patchwork of one-offs and workarounds that has accumulated over the past decade.

The bill also amends five federal securities laws to clarify that balances held with registered covered providers do not constitute securities, removing a legal ambiguity that has historically made nonbank payment product development less viable.

The Real Story Is Infrastructure, Not Access

The temptation is to read PACE as a “fintech access” bill, a regulatory upgrade that lets a few qualified nonbanks join the club. That framing misses the bigger change.

PACE recognizes a payments architecture that operates in parallel to the bank-mediated one. Correspondent-banking models will continue to handle the workloads they were designed for, including international rails, FX, and the long tail of payment types where bank intermediation remains the right answer. PACE adds a directly chartered category alongside that model for software-native financial products that need instant, conditional, programmable settlement that are properties of an infrastructure layer, not features that retrofit cleanly onto batch-processing back ends.

For builders, the implications are immediate. Qualified-nonbank eligibility is a compliance posture, not a corporate transformation. Providers that have already built around continuous attestation, real-time monitoring, segregated custody, and audit-ready controls are in a fundamentally different position than providers that treat compliance as a periodic reconciliation.

The PACE bar is high, but it is the bar that 

The same is true on the settlement side. Programmable settlement ( T+instant flows, conditional release, AI-orchestrated routing across rails) is a property of an infrastructure layer built natively against federal rails. PACE recognizes that posture as a federally chartered option, sitting in parallel to the sponsor-bank path rather than displacing it.

The PACE Act is good policy. It is rigorous where it needs to be: strict reserves, explicit consumer protections, continuous regulatory oversight, and insolvency rules that put customers first. It is also genuinely productive in removing an artificial structural barrier that currently inhibits competition and imposes unnecessary costs on consumers.

But the lasting effect of PACE will not be measured in how many fintechs eventually clear the qualified-nonbank bar. It will be measured in what happens to the rest of the market once direct rail access is no longer hypothetical.

Pricing power redistributes across more participants. Builders gain an architectural choice between the sponsor-bank model and direct rail access, and they can pick the path that fits their product rather than defaulting to the only one available.

For the next generation of programmable dollar infrastructure, that question has already been answered.

Dakota’s infrastructure assumes direct rail access as the architectural default, not the regulatory exception. With $3B+ processed across 700+ customers, we built the architecture for the world PACE is creating before it had a regulatory shape.

The PACE Act and the New Shape of Payments Infrastructure

When SVB collapsed in March 2023, it didn't just expose concentration risk. It revealed how fundamentally reactive many corporate treasury functions had become.

CFOs scrambled to diversify bank relationships, only to discover what treasury teams already knew: opening accounts takes months, moving money takes days, and getting up-to-the-minute visibility across entities requires accessing a dozen banking portals and wrangling multiple spreadsheets.

The problem isn't competence. Treasury teams are strategic, risk-aware, and operationally sophisticated. The problem is infrastructure. Banking rails impose artificial constraints like cut-off times, pre-funded correspondent accounts, multi-day settlement windows, and entity-by-entity provisioning. These constraints make continuous cash management operationally impossible. You can't build software-speed operations on hardware-era rails.

Stablecoins eliminate those constraints and unlock faster, more programmable treasury operations. Unlike other fintech solutions, stablecoins don’t bolt faster interfaces onto the same underlying plumbing. Instead, they replace the settlement layer entirely. Treasury can evolve from a quarterly planning exercise constrained by bank functionality into a real-time tool for businesses to manage risk.

The Six Structural Bottlenecks Legacy Banking Imposes

The operational ceiling that treasury teams contend with today is a result of legacy infrastructure. Six constraints, inherent to traditional banking architecture, force even well-resourced treasury teams into reactive, manual workflows:

 Every subsidiary needs its own bank accounts. Every bank has its own portal, API schema, and reconciliation format. Aggregating simultaneous cash positions across a global, multi-entity organization means logging into multiple systems, exporting CSVs, and rebuilding the full picture in a spreadsheet.

Legacy TMS infrastructure that can't adapt.

 Enterprise treasury management systems promise centralized control. But replacement cycles run multiple years, implementations cost millions, and most mid-market companies struggle to justify the investment. So they run treasury in spreadsheets, sacrificing automation and auditability because the alternative is an expensive, multi-year IT project.

 Treasury teams are small and tend to be risk-averse. That means low transaction volume. As a result, organizations often treat the team as a cost center rather than a revenue driver. This bias causes treasury teams to receive slow support and limited investment when it comes to tooling and technology.

Risk aversion that locks in inefficiency.

 Treasury exists to avoid catastrophic mistakes, which creates institutional bias toward the status quo. Switching banks is risky. Adopting new settlement rails is risky. The safest move is always incremental improvement on what’s already in place, even when it’s structurally incapable of delivering what the business needs.

Dependency on bank-by-bank relationships.

 Want to expand into a new country? You need a local entity and local bank accounts. Opening those accounts takes weeks to months. Then, you're stuck pre-funding them because cross-border settlement is slow and expensive. And now you've added another reconciliation headache to your monthly close process.

Talent constraints that amplify operational drag.

 Treasury is a specialized function. Hiring and training take time. When your infrastructure requires manual reconciliation, constant firefighting, and institutional knowledge to navigate bank-specific quirks, you can't scale the team fast enough to support business objectives. Operational drag compounds.

These six bottlenecks trace back to a banking system designed for a pre-internet world. Stablecoins eliminate them.

Four Capital Efficiency Unlocks Stablecoins Enable

Stablecoins replace the settlement layer, which changes what's operationally possible. Four shifts unlock capital efficiency that legacy rails make impossible:

 Instead of fragmenting cash across entity-specific bank accounts, stablecoins let you pool liquidity in a single layer and allocate it programmatically. Need to fund a payment from your Singapore subsidiary? You don't need a pre-funded Singaporean bank account; you settle directly from the unified layer.

 Traditional cross-border payments require nostro/vostro accounts held at correspondent banks. Stablecoins settle near-instantly on shared infrastructure, so there's no settlement risk to backstop. The working capital that was previously locked up in correspondent accounts goes back onto your balance sheet.

Establishing continuous intercompany netting.

 Monthly intercompany settlement means waiting until month-end to reconcile, net out offsetting flows, and execute transfers. By the time you settle, the business has already moved on. Stablecoin rails let you net in real time, so intercompany balances and FX spread costs don't balloon unnecessarily.

Measuring onboarding measured in hours (not months).

 Consider what this looked like before: incorporate, open bank accounts, wait for compliance review, fund the accounts, then integrate them into your TMS — weeks to months of lead time. With stablecoins running on compliance-as-code infrastructure, you deploy a wallet, assign permissions, and start transacting. The compliance layer is already built in.

These are step changes in what a treasury team can do. We know stablecoins are faster. So what is the cost of staying on banking rails? The question is whether your business can tolerate the cost of staying on banking rails.

Real-Time Settlement Changes Treasury's Operating Model

Speed matters, but not because faster payments are inherently better. Speed matters because it changes what you can optimize for.

 take days. That delay isn't just inconvenient; it forces you to hold larger cash buffers, pre-fund accounts you might not need, and lock in FX exposure earlier than you'd like. When settlement is slow, treasury becomes a game of predicting future needs and defensively over-provisioning to avoid getting caught short.

Stablecoin settlement happens in minutes, turning treasury from defensive forecasting to real-time response. Instead of trying to predict what you'll need and hoping you got it right, you move capital exactly when and where it's needed. Cash buffers shrink because you're not defending against multi-day settlement lag. FX exposure windows compress because you can hold dollars until the moment you need local currency.

The same logic applies to intercompany flows. When your European entity owes your US parent, traditional settlement means initiating a wire transfer, waiting two to three business days, and hoping FX rates don't move against you in the meantime. Stablecoin settlement collapses that window to minutes.

The result is a shift in treasury’s role: from a function that manages constraints to one that drives capital efficiency. Instead of defending against infrastructure limitations, treasury becomes an active lever for business performance — optimizing cash deployment, compressing FX windows, and enabling faster expansion into new markets.

Treasury has been constrained by the same infrastructure for decades. Fragmented liquidity. Slow settlement. Pre-funded accounts. Entity-by-entity provisioning. They were the defaults of a banking system built for a pre-internet world.

Stablecoins eliminate those constraintsby replacing the settlement layer entirely. Treasury operations become programmable: unified liquidity, instant cross-border settlement, and entity infrastructure that scales at software speed instead of banking speed.

Companies are adopting stablecoin rails because their business strategy can't wait for traditional banking to catch up. If you're expanding globally, managing multi-entity structures, or operating in volatile FX markets, the infrastructure constraint is already costing you. 

 provides the regulated primitives — custody, compliance, payouts, and treasury — that let you act on it. 

Treasury at the Speed of Software

Finance teams spend more time extracting data than acting on it. They file tickets, wait for engineering, and by the time the report arrives, the window to use it has narrowed. The problem isn’t a lack of data. It’s that the intelligence needed to interpret it sits in a separate tool, far from where the data actually lives.

Dakota’s platform ingests and normalizes transaction, customer, and billing data, then makes it queryable in plain English.

When a user asks, "Show me fee revenue by client segment for Q1," the system interprets the question, queries the normalized data, and returns structured results through a single API. Alongside the data, it recommends a visualization based on what the user asked, and surfaces related reports which others have run on similar queries.

This isn't a suite of five separate tools. It's a sequential capability stack where each layer builds on the one below. And because the intelligence lives at the data layer, it works the same way whether the user is a product manager in a web app, a finance team in Excel, or an autonomous AI agent querying via API.

The architectural distinction matters. Application-layer BI tools sit on top of data warehouses and require users to understand the underlying schema or pre-built dashboards. When you add conversational AI to application-layer tools, the intelligence doesn't understand the data model natively, can't guarantee consistency across queries, and can't serve both human users and AI agents through a single interface.

Dakota's API-first design at the data layer means:

 Every query — whether from a human or an agent — runs against the same normalized schemas and returns auditable results

 Non-technical users and AI agents query the same system without SQL

 Queries, visualizations, and recommendations compose into workflows without switching tools

The Experience: From Questions to Insights in Seconds

A Head of Finance preparing for a board meeting needs to understand why transaction volume spiked in one corridor last quarter and whether it held. Traditionally, this means filing a request with data engineering, waiting for a custom report, and iterating when the first pass doesn't answer follow-up questions.

With Dakota, they open the Reports tab and type: "Show me transaction volume by corridor for the last six months." The system identifies the relevant transaction data, segments by payment corridor, and returns a time-series dataset with a grouped bar chart (and suggests other related reports). It’s ready in seconds. If the follow-up is "What's driving the Q4 spike in the Mexico corridor?", they ask it directly.

This workflow extends beyond human users. Autonomous AI agents responsible for monthly reporting can query the same API, generate the same insights, and assemble them into board decks without human intervention. The data layer provides consistent, auditable answers whether the analyst is a person or a process.

The impact shows up in decision cycles. Teams that previously waited days for custom reports can now iterate on questions in real time. Finance operations leaders who spent hours manually extracting data now spend that time interpreting insights. And data engineering teams shift from building one-off reports to overseeing scalable, self-service analytics.

The phrase "democratizing data" is overused, but the underlying goal remains critical: enable anyone who needs an answer to get one, without bottlenecks. In financial services, this isn't just a productivity improvement. It's a strategic imperative.

Cross-border money movement platforms operate in environments where data literacy varies widely. Product teams, compliance teams, treasury teams, and partner teams all consume the same transaction and ledger data but have different technical capabilities. A data architecture that requires SQL expertise or data engineering support creates gatekeepers. A data architecture with intelligence at the layer where data lives removes them.

This also unlocks agentic workflows. As AI agents take on tasks like monthly reporting, portfolio rebalancing recommendations, and client communication, they need direct access to institutional data. If analytics intelligence lives only in application-layer tools designed for humans, agents can't participate. When it lives at the data layer, agents query the same API humans use—no special integrations, no parallel systems.

The combination of human and agentic access at the data layer compounds value. A finance analyst asks a question, gets an answer, and refines the query. An AI agent monitoring the same data notices a pattern, generates a report, and flags it for review. Both workflows run on the same infrastructure, producing consistent, auditable results.

This is the shift from analytics as a specialized function to analytics as a foundational capability.It’s embedded in daily operations, accessible to all team members, and ready for both human and machine consumers.

The problem with most analytics platforms is that they add AI in the wrong place. Conversational dashboards and natural language query boxes at the application layer still require users to navigate fragmented tools, understand data schemas, and wait for engineering support. The intelligence is too far from the data.

Dakota embeds analytics intelligence at the financial data layer itself, where institutional data is already normalized, structured, and ready to query. This architectural choice eliminates the gap between asking questions and getting answers. Finance teams, operations leaders, and AI agents all query the same system, through the same API, with the same institutional-grade consistency.

The result: faster decisions, fewer bottlenecks, and a data architecture ready for the next generation of institutional workflows, where humans and agents collaborate on the same foundation.

If your team spends hours extracting data instead of interpreting insights, the problem isn't lack of effort. It's that the intelligence doesn't live where the data lives. Dakota changes that.

The Reports Tab: Ask Your Data Anything

. Unlike the formal networks that support domestic payments, the system that enables cross-border payments is informal. And by most measures, it’s a system that works.

But it doesn’t work for everyone. Look closer and speed targets are being missed, costs remain well above G20 benchmarks, and entire regions are structurally underserved.

The problem isn’t effort. Significant resources have been directed at improving global payments for years. The problem is architecture. The correspondent banking system—the informal network of interbank relationships that underlies most cross-border transactions—was not designed for the speed, cost, and availability that modern businesses require.

How the Correspondent Banking System Actually Works

Every cross-border payment involves two things: a message and a money movement. SWIFT handles the messaging; when you initiate a payment, your bank sends instructions that travel institution to institution down the chain. But SWIFT doesn’t move money. Money moves through the correspondent banking network, a system of pre-funded accounts that banks hold with each other.

In the simplest case, your bank holds a pre-funded account at the recipient’s bank, debits it, and the recipient is credited. In practice, that direct relationship often doesn’t exist. When it doesn’t, intermediary banks step in to bridge the gap. 

 shows each additional intermediary adds three to four hours of processing time.

The distribution of those intermediaries is not random. High-volume corridors — US to Canada, Germany to France — tend to have direct bilateral relationships and settle quickly. Low-volume or “thin” corridors require more hops. A payment from New York to Toronto clears in minutes. The same payment to Nairobi or Karachi can take days. That disparity is baked into the architecture.

The G20 has set benchmarks for cross-border payments across four dimensions: speed, cost, coverage, and availability. On all four, the system is behind.

On speed, the target is 75% of payments credited within one hour by end of 2027. Currently, 

54.6% of wholesale and 46.4% of P2P payments

 meet that bar. Regional variation is significant: 73% in North America, 24% in Sub-Saharan Africa. The bottleneck is typically the beneficiary leg, where compliance checks, FX conversion, and batch processing windows compound.

On cost, the G20 target is a 1% global average. B2B currently averages 1.6%; P2P averages 2.6%. P2P costs are structurally elevated because roughly 

 are remittances, with 75% going to low- and middle-income countries. These corridors feature thin competition, wide FX spreads on illiquid currency pairs, and cash-heavy last miles.

On coverage and availability, the picture is similarly uneven. The number of active correspondent banking relationships has 

 since 2011, with higher-risk markets down as much as 60%. Fewer direct relationships mean more intermediary hops—and higher costs—in the corridors that can least afford them. And while SWIFT operates continuously, the money movement layer runs on banking hours. A payment initiated Friday afternoon in one timezone may not clear until Monday in another.

Cross-border payments volume is increasing by between 5-10% per year, 

. So the structural gaps in correspondent banking aren’t abstract. They create real operational costs for businesses that depend on moving money across borders.

And, with more businesses offshoring operations and leveraging global supply chains each year, the impact of these inefficiencies is only growing.

Let’s look at three sample use cases for businesses dealing in cross-border payments:

Example 1: A crypto exchange operating across 12 jurisdictions needs to cover withdrawal spikes in real time. When a market move creates a liquidity shortfall in Brazil at 4pm on a Friday, the exchange can’t remediate it until Monday because settlement windows between US and Brazilian correspondent banks don’t align on weekends. The practical response is to hold larger idle balances in every jurisdiction, tying up capital that could otherwise be deployed productively.

Example 2: A fintech building a global payout product hits a different constraint: coverage. The platform works well in high-volume corridors with established direct relationships, but each new jurisdiction requires rebuilding bilateral banking infrastructure from scratch. Months of relationship-building and regulatory work before a single payment can be processed. Coverage gaps show up in production, not in planning.

Example 3: A mid-sized technology company running payroll across 22 countries finds that eight settle predictably (where the company has local entities and direct banking relationships). The remaining 14 route through multiple intermediaries. FX is applied at unpredictable points. Each intermediary runs its own AML, KYC, and sanctions screening independently. As a result, the payroll cycle costs 3–4% more than it should, with settlement windows ranging from one to five business days depending on the corridor — and no notification when a compliance flag creates a delay downstream.

Stablecoins are dollars that move on blockchains. That simple difference has significant structural implications for cross-border payments.

In correspondent banking, value moves by adjusting balances in pre-funded accounts across a chain of institutions. In a stablecoin transaction, tokens move directly from one address to another. A cross-border payment can involve two parties rather than six. Compliance is applied once at the orchestration layer, with full on-chain visibility, rather than duplicated by every intermediary in the chain.

The growth numbers reflect this advantage. An estimated $390 billion in payments moved on stablecoin rails in 2025—more than double the prior year. Around 60% of that volume is B2B, concentrated in the US, Singapore, Hong Kong, and Japan. Notably, these are corridors where correspondent banking already performs well. Stablecoins are winning where legacy rails are strongest, which points to structural advantages rather than just filling coverage gaps.

This doesn’t mean stablecoin payments are frictionless today. On/off-ramp infrastructure is uneven across geographies. Gas fees and swap costs apply, though on high-throughput chains they’re negligible for large B2B transactions. And stablecoins don’t speak SWIFT natively—though orchestration platforms can accept SWIFT-formatted instructions and settle on stablecoin rails, allowing enterprises to adopt without rearchitecting their treasury integrations.

The correspondent banking system’s shortfalls on speed, cost, coverage, and availability are not fixable through optimization. They’re the result of an architecture built on pre-funded accounts, sequential compliance checks, and settlement windows that only run during business hours.

Dakota is building the infrastructure layer that doesn’t carry those constraints. The platform supports stablecoin and fiat settlement across 100+ jurisdictions, with SWIFT integration, compliance embedded at the transaction level, and settlement that runs 24/7.

For the crypto exchange, that means the Brazil shortfall resolves in minutes, not on Monday morning. For the fintech, expansion into a new market is a configuration discussion, not a months-long project. For the payroll team, costs are predictable and settlement timing is consistent across corridors.

The global payments system is missing its benchmarks because the underlying architecture has limits that no amount of incremental improvement can overcome. The alternative is already in production.

Why "Global Payments" Almost Never Means Global

The AI-in-fintech market is on its way from $15.4 billion to $60.6 billion by 2033, according to 

). This number reflects growing demand. CFOs and finance leaders are aware that manual processes, reconciliation delays, and slow treasury decisions don’t have to be the norm. They want financial infrastructure that can keep pace with their business's evolving needs.

But instead of revolutionary tech, what’s on offer in many cases is a legacy system with a chatbot bolted on top.

Today, the prevailing approach to "AI-powered finance" is augmentation: take infrastructure designed for humans, add a layer of machine learning or a copilot interface, and call it intelligent. This approach allows teams to apply AI to specific tasks, but it doesn’t harness the power of autonomous agents at the infrastructure level.

Dakota is building something categorically different. Not AI that assists financial operators, but financial infrastructure that thinks, learns, and does. We call it Intelligent Capital.

Most financial AI implementations fall into two categories: predictive analytics that surface recommendations, or automation that handles defined rule-based tasks.

Intelligent capital is different. It’s financial infrastructure where AI agents independently manage and execute financial actions within human-defined parameters.

It’s a key distinction. Legacy financial infrastructure was designed around a human-in-the-loop model. The technology supporting every critical decision (approve this payment, route this capital, flag this anomaly) was designed under the assumption that a person would review and act. When you layer AI onto this architecture, you're fitting machine-speed intelligence into human-speed rails. The AI might surface an insight in milliseconds, but legacy infrastructure isn’t equipped to convert these insights into action at the same pace.

Augmenting legacy systems with AI can deliver better dashboards, smarter alerts, and faster reporting. However, these improvements still have to work around the constraints of the systems they inherited. You can't make infrastructure intelligent if it was never designed to act intelligently.


Intelligence as a Primitive, Not a Feature

Dakota was built on a different premise. When we designed the infrastructure, we treated intelligence as a first-class primitive at the same level as payments, ledgers, and capital routing. Not an add-on. Not a layer. A structural component in the system.

What that means in practice: the infrastructure itself can evaluate conditions, execute decisions, and reason about capital flows. Humans set the parameters and oversee the outputs, but AI agents are empowered to manage the operational minutiae.

In an AI-augmented model, the legacy system distributes data and waits. In an AI-native model, the system can close the loop between observation, decisioning, and action within the infrastructure itself.

Because Dakota builds AI-native infrastructure, we don’t have to retrofit existing systems. We assume that the infrastructure must be able to act autonomously.


MCP: Making Financial Infrastructure Machine-Readable

One concrete expression of this architecture is Dakota’s MCP server integration. Dakota's core financial operations are available as machine-readable API endpoints that AI agents can directly read, interpret, and act on.

This matters because most financial data, even in modern systems, isn't actually machine-accessible in a native way. It might be available via standard API, but the processes required to ingest that data, understand its context, and take action on it were all designed around human interpretation.

MCP changes that. When Dakota's financial primitives are exposed through MCP, an AI agent can query account states, evaluate capital positions, and execute financial operations. Agents are also increasingly skilled at understanding the full context of those operations without the need for human interpretation. The infrastructure and the intelligence speak the same language natively.

For CFOs evaluating infrastructure roadmaps, this is the most relevant technical distinction. Can AI agents operate directly inside your financial infrastructure, or will they be stuck operating one translation layer removed from actual capital?


Autonomous FinOps and TreasuryOps in Practice

What does intelligent capital actually look like from the standpoint of your finance team?

Dakota’s agent-driven workflows support two categories of intelligent agents operating natively inside the infrastructure: FinOps agents that optimize capital flows and surface anomalies in real time, and TreasuryOps agents that automate treasury management across assets and entities.

Rather than eliminating human judgment entirely, the goal is to keep people involved where they add the most value: defining goals and guardrails before the system runs, and reviewing outcomes and refining policies after it does. In this model, people aren’t removed from the loop, they move to the highest-leverage positions in it.

Consider a multi-entity operation managing capital across subsidiaries in different currencies, with varying liquidity requirements and time-sensitive obligations. In a traditional system, treasury optimization is a daily or weekly exercise: gather data, model positions, make decisions, and execute transfers. A skilled team does this quickly, but it's still a cycle measured in hours or days.

In an AI-native infrastructure, the cycle compresses dramatically. Agents continuously evaluate capital positions against defined objectives, identify optimization opportunities in real time, and execute. Agents can also surface material decisions for approval, depending on human-defined thresholds.

Two concrete examples illustrate how this works in practice:

We rewrote our API documentation and surface area to be optimized for agentic consumption. Our APIs give agents the context they need to understand patterns, workflows, and the sequencing logic that agents still struggle with when operating without guidance.

We’re building a policy engine designed to be a key guardrail for autonomous money movement. This goes well beyond simple spending limits. Instead of “this agent can spend $10,” the policy engine enforces rules like “this agent can spend up to $10 at these approved vendors or categories during this specified time period,” with a full audit trail documenting what was spent and which policy authorized each transaction. Human oversight is preserved at the policy level, not the transaction level.

Radically faster workflows are one consequence of building intelligence into the infrastructure from the start. But much more is possible; agents’ ability to learn and iterate means that processes across the financial stack can be tailored to run like clockwork, following specific AI-native instructions and data practices.

If you're evaluating financial infrastructure right now, the standard evaluation criteria (like integration depth, pricing models, compliance coverage, and support quality) still apply. But there's a new axis that most evaluation frameworks haven't caught up to yet: is this infrastructure capable of autonomous operation?

Can AI agents read financial state directly, without a human translation layer?

Can the infrastructure execute decisions against defined objectives, or does every action require human initiation?

Is intelligence a feature you turn on, or an architectural property of how the system operates?

These questions can determine whether your financial infrastructure can actually support intelligent automation at scale, or whether you’ll hit a ceiling the moment you try to reduce the burden on human operators and route their attention toward higher-value decisions.

Fintech is embracing AI, and investors' growing enthusiasm reflects genuine demand from operators. But most of what's being sold as AI-powered finance today is really AI augmentation of legacy infrastructure, and truly AI-native technologies like Intelligent Capital are only coming to market now. Businesses that understand the distinction stand to capture the vast majority of the value that AI is expected to produce going forward.

——————————————————————

Intelligent capital isn't a feature set. It's an architectural category referring to infrastructure that was designed to express intelligence, not accommodate it.

At Dakota, we build financial infrastructure where intelligence is structural, and where AI agents can operate natively inside capital flows. Autonomous decision-making is a property of the system rather than an aftermarket addition.

For CFOs and finance leaders building toward faster, more intelligent operations: the infrastructure decision you make now determines what’s actually possible at scale. If you’re layering intelligence onto human-oriented rails, you’re going to hit the ceiling faster than you expect—not because humans are the problem, but because the infrastructure was never designed to keep pace.

The question isn't whether your platform has AI. It's whether your infrastructure is built for the AI age.

Intelligent Capital: How Dakota Embeds AI Directly Into Financial Infrastructure

There's a conversation that happens in nearly every growth-stage fintech, and it usually goes something like this: engineering ships the feature, legal inherits the artifact, and somewhere in the handoff, a two-week timeline becomes a two-month delay. The product is done. The market is ready. The thing sitting between you and revenue is a stack of review cycles that no one has figured out how to compress.

This isn't bad luck. It's a structural problem: most fintechs treat compliance as a gate rather than a layer. They sequence it after the engineering work is finished, hand it to teams who weren't part of building it, and then act surprised when the review process generates as much back-and-forth as the build itself.

With so much back-and-forth, it’s not surprising that 93% of fintechs said it was somewhat or very challenging to meet compliance requirements, according to 

Alloy’s State of Compliance Benchmark Report

State of Regulatory Affairs and Compliance Report

 found that these challenges led to more than one-third of organizations in regulated industries missing a regulatory requirement in the past 12 months, and amongst those, 46% faced delayed or canceled product launches.

But those outcomes aren’t inevitable. They're a design choice.

The fastest fintechs have figured something out: compliance is an engineering problem that legal teams have been left to solve on their own. When you change that — when you embed compliance into the development process the same way you'd embed security or observability — the review cycle compresses, the risk exposure shrinks, and you ship.

Before making the case for a different model, it's worth being precise about what the current model costs because "compliance is expensive" is too vague to motivate real change.

 found that non-compliance costs are 2.71 times higher than the cost of maintaining compliant operations. That gap comes from fines, remediation, rework, and the compounding opportunity cost of launches that slip by months. 

Global regulatory fines hit a record $19.3 billion in 2024.

Global financial crime compliance spend has crossed $206 billion annually.

But the less-discussed cost is velocity. When a compliance review takes four months instead of six weeks, that's not just a calendar problem. It's a competitive window that closes, a customer segment that signs with someone faster, a market position that erodes while you wait for sign-off on something that was already built. The delay isn't just expensive in the moment. It compounds.

The paradox is that nearly none of this delay is generated by regulators. It's generated internally, by the processes fintechs use to manage compliance work. That's what makes it fixable.


Compliance-as-Code: The Engineering Reframe

The highest-leverage intervention available to fintechs right now is encoding your compliance program—your policies, procedures, risk ratings, and controls—as testable definitions rather than narrative documents reviewed after the fact.

Regulatory requirements are one input to that program, but they’re rarely the bulk of the work. The more substantial work is translating those requirements into your organization’s specific risk posture: defining customer risk tiers, determining what thresholds trigger manual review versus automated approval, and continually refining those decisions based on what you learn from actual customer behavior on the platform. That institutional logic is what compliance-as-code captures and makes auditable.

Compliance-as-code works the same way security-as-code does: instead of running a security audit after the system is built, you encode security requirements into your CI/CD pipeline and catch violations before they reach a human reviewer. Compliance-as-code applies the same logic to KYC/AML workflows, data residency requirements, transaction monitoring thresholds, and change-management controls.

When your compliance program moves from policy documents to version-controlled, codified policiesthree things happen. First, it becomes testable: you can run your risk logic against a proposed change before it ships. Second, it becomes auditable; the history of what your policy was, when it changed, and who approved the change is part of the same artifact trail as the code itself. Third, it becomes legible to engineering teams; developers can understand what’s required without waiting for a compliance interpretation of a 40-page regulatory document.

The back-and-forth that consumes most compliance delays is usually caused by ambiguity: compliance asks a question that engineering can’t answer without looking at code, engineering makes a change that compliance didn’t anticipate, and the cycle repeats. Compliance-as-code eliminates most of that surface area before it opens.

The second structural change that separates fast fintechs from slow ones is when compliance gets involved, not whether they do.

The traditional model treats compliance as a review function: engineering builds, compliance reviews, compliance finds problems, and engineering goes back to fix them. Each iteration adds weeks. The alternative is to embed compliance context into the design phase, before architecture decisions are made, and the cost of changing course is high.

This doesn't mean compliance signs off on every sprint. It means compliance requirements are documented in product documents, that the team building a new payments flow has spoken with someone who understands the applicable regulations before writing a line of code, and that the end-of-cycle review is confirmation rather than discovery.

Teams that operate this way report shorter review cycles, not because the requirements changed, but because the artifact handed to reviewers arrives without the gaps that generate iterations. The review isn't a negotiation; it's a sign-off on something that was designed to pass.


Automate the Audit Trail, Not Just the Workflow

Regulatory reviews are expensive partly because producing the evidence they require is expensive. When an examiner asks for a history of how a control was implemented, who approved it, and whether it was tested, the answer usually involves someone manually reconstructing a timeline from emails, Jira tickets, and scattered documentation.

Fintechs that automate audit trail generation as a first-class output of their engineering process change that calculus completely. Every deploy, every policy change, every test result becomes a structured record that can be surfaced on demand. The response to a regulatory inquiry can range from a multi-week documentation project to a query, and with AI, anyone can now run these queries.

This matters operationally, but it also matters strategically. Fintechs that can demonstrate robust, automatically generated audit trails build credibility with regulators over time. That credibility compounds: the second review cycle is shorter than the first, the third shorter than the second. The investment in automated audit infrastructure pays dividends across every future regulatory interaction.

None of this happens without a deliberate decision to own compliance as an engineering problem. That decision has to come from the CPO or CTO, because it requires reallocating engineering capacity toward compliance infrastructure before there's immediate product pressure to do so. It's the same trade-off as investing in observability or test coverage: the payoff is invisible until the moment it isn't.

Blog

The PACE Act and the New Shape of Payments Infrastructure

Treasury at the Speed of Software

The Reports Tab: Ask Your Data Anything

Why "Global Payments" Almost Never Means Global

Intelligent Capital: How Dakota Embeds AI Directly Into Financial Infrastructure

How Compliance Bottlenecks Slow Fintech Growth (and Practical Ways to Fix Them)

Onboarding Timeline Comparison: Traditional Banking vs. Dakota

We Built a Neobank in 9 Hours. Here's Why That Changes Everything.

Ship Faster, Stay Focused: Building Global Money Movement Without the Infrastructure Tax