We’ve applied to the U.S. Office of the Comptroller of the Currency for a national trust bank charter.

Today, Dakota operates in the U.S. as a registered Money Services Business. A National Trust Bank Charter would position Dakota as a federally regulated provider of digital asset custody, stablecoin issuance, and related services, and a partner of choice for corporate and institutional clients building on us.

For you, that means fewer layers between your product and the financial services underneath it. Fewer intermediaries mean more control, more reliability, and a cleaner experience for the people you serve. That’s always been the point: the less that sits between you and what you’re building, the better the product you can put in front of your customers.

It’s the same reason we became infrastructure in the first place. There are so many hurdles that make building financial products hard: distributed licensing, compliance that runs as a periodic scramble instead of as code, payment rails never built for programmable or agent-native money. So instead of working around that, we rebuilt from the foundation and became the layer underneath.

Nothing about this changes what you rely on today. The application is in. The work continues. And it’s all pointed at making what you build easier, more reliable, and more possible.

Dakota Applies for a National Trust Bank Charter

In February, our team built a complete, production-ready neobank in nine hours.

Not a demo. Not a Figma mock. Real accounts, real flows, real compliance guardrails.

That sentence would have sounded absurd even a year ago. In fintech, time to market has been capped by regulation, partnerships, and months of back-and-forth with vendors. We’ve taken care of all that, so your team can focus on building your product. And this reshapes who gets to compete.

This isn't a story about engineering bravado. It’s a story about a market hitting an inflection point.

The Neobanking Market Just Compressed…Again

The first wave of modern neobanks took something like $2M and 14 months to get to market. Founders had to stitch together a sponsor bank, compliance consultants, bespoke vendor integrations before they could build a product. The barrier to entry was the complexity of that work, as well as the time and money it cost.

The next wave compressed that dramatically. Platforms emerged. APIs standardized. Timelines shrank to 6–12 months, budgets to low six figures.

Last weekend, we proved a new phase that eclipses previous progress. Production-ready in 9 hours.

That speed is only possible because we spent the last 2 years doing the slow, difficult work of laying a technical and regulatory foundation for our platform: Scalable infrastructure. Payment processing. Licensing. Risk frameworks. Control structures.

We don’t move fast despite compliance. We move fast because of it. And this foundation changes everything.

Engineers aren't blocked by complex vendor tooling and integrations. Product teams don’t wait on manual compliance reviews to ship. Compliance and reliable infrastructure accelerate your team rather than slow them down.

The platform unlocks speed. But what you do with that speed depends on how you build.

Right now, more than half of API documentation is consumed by AI agents, not humans — and that number will only grow. So we’ve made a deliberate bet: assume developers use AI. That assumption now shapes everything we touch.

Our endpoints are designed for clear AI interpretation. Our documentation is structured for agents. We're actively building toolkits so AI can do the heavy lifting on development tasks, freeing the humans on your team to focus on planning and review.

Similarly, our new AI-powered dashboard features follow a describe-review-approve workflow that replaces the last generation of interaction-heavy UIs. AI-driven custom analytics and workflow automation are already in development.

This isn't a side project. We have engineers dedicated specifically to making AI-assisted neobank builds faster and more reliable than anything else on the market.

By leveraging our compliance-first infrastructure and AI-first development platform, the distance between idea and complete execution compresses like we’ve never seen before.

For years, venture-scale neobanks chased horizontal markets because compliance overhead demanded massive TAMs. If you were serving a niche, the math didn't work. The cost of entry once forced you to think big or not at all.

That constraint is disappearing. And what replaces it is something more interesting than another challenger bank.

Think about it: when an engineer can rebuild vendor tooling in hours and demonstrate end-to-end banking infrastructure in a single day, technology differentiation evaporates. The moat isn't how fast you can build anymore — it's what you're allowed to build and who you build for.

What we will see is a long tail of focused, opinionated financial products: companies building sustainable businesses serving verticals that were previously invisible to fintech.

Industry-specific cash management. Workflow-embedded banking. Communities and professions with unique regulatory or cash-flow needs that no horizontal platform ever bothered to understand.

These products redefine the market. Financial services don’t consolidate from here — it fragments. And the founders who win will be the ones who went narrowest, understood their customer most deeply, and built something that couldn't have existed two years ago.

That future just got a lot closer. And we built the platform to get you there.

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

Stablecoin adoption is maturing. And, as it does, the underlying technology is becoming invisible to end users.

A business sending a cross-border payment through a modern platform doesn’t necessarily manage wallets, blockchains, or stablecoins. What the payer and recipient experience is speed, reliability, and cost. And increasingly, those qualities are equivalent across leading platforms.

As the market matures, the underlying rails get abstracted away, and competition shifts to what’s built on top of them. As performance converges into table stakes across leading providers, the partnership decision comes down to something else.

It comes down to compliance as a stack: the set of tools and processes a provider uses to enforce policy, screen transactions, and manage risk. As internet-native rails collapse cost, speed, and transparency into commodities, the compliance stack is what will separate the payment providers that scale from the ones that stall. The companies building it now are the ones positioned to lead.

Compliance is a common point of failure. Payments can be delayed because a transaction triggered a rule that wasn't calibrated to the corridor. Customer accounts can be frozen because a flag wasn't resolved before a settlement window closed. Expansion into a new market can stall because the existing compliance architecture wasn't built to accommodate a different regulatory framework.

These are not edge cases. They are the reason payment products underdeliver in production. Compliance challenges regularly derail or delay fintechs, payroll platforms, crypto exchanges, and other businesses that transact across borders.

Yet most of the industry has stayed focused on building out the payment rails themselves.

As the ecosystem matures, however, performance parity will make compliance the deciding factor. How screenings are applied, how the system adapts to new regulatory requirements, or how exceptions are managed during non-bank hours in exotic corridors. These differences will determine which platform wins in a performance-agnostic world.

Legacy compliance architecture was designed for batch processing and periodic review cycles. It was not built for real-time, global, programmable settlement.

In practice, that means AML, KYC, and sanctions screening run sequentially and independently at each institution in the chain. The same payment can be screened multiple times, by institutions that don't share results, producing delays that compound across corridors and time zones.

The deeper problem is structural. In legacy systems, compliance is a property of the workflow and grafted onto the transaction process rather than embedded in it. That makes it expensive to maintain, slow to adapt when regulations change, and inconsistent in markets where institutional relationships are uneven. The compliance burden gets passed downstream to the payment providers and, ultimately, to their end users.

 takes the opposite approach: a payment is screened once, at the platform that originates it, before it moves. Every participant in the path sees the same result, rather than running its own redundant check.

In practice, that means controls (limits, holds, additional verification, blocking) apply dynamically as customer behavior evolves, not against a static profile captured at sign-up. Permissions and flows adjust in real time, with behavioral re-evaluation as the norm and periodic reviews as the floor.

AML screening runs at the orchestration layer rather than downstream. Sanctions lists are applied in real time. Exceptions generate automated workflows with clear audit trails. Compliance lives in the product. Controls execute in code, not in tickets.

Whereas the correspondent banking system is essentially a game of telephone between banks in different countries, internet-native payment rails (like stablecoins) can carry identity and transaction data through the full lifecycle of a payment, available to every participant. The result is fewer delays and more consistent enforcement of compliance rules.

The operational difference for payment providers is significant. Onboarding that previously took weeks compresses to hours. Expansion into a new market becomes a configuration decision rather than a months-long compliance buildout.

The compliance posture becomes a property of the infrastructure itself, rather than an artifact of a given correspondent banking relationship.

Modular Architecture Adapts; Monolithic Architecture Doesn't

Compliance also poses an adaptability problem. Regulatory requirements change: new watchlists, updated KYC standards, jurisdiction-specific reporting obligations. Legacy financial infrastructure was built as a monolith, in which tightly integrated systems mean that changing one component requires changing many others. Adapting to a new requirement often means a multi-month engineering cycle, not a configuration update.

Modular compliance architecture separates each function (screening, custody, reporting, policy enforcement, etc.) into a discrete component that can be updated independently. When OFAC updates a list, the screening layer reflects it without necessarily affecting custody. When a new market requires a different KYC standard, the policy layer adapts without demanding a settlement layer re-architecture. The system is designed to evolve at the speed that’s required.

For companies transacting across multiple jurisdictions, this is the difference between a platform that can scale globally and one that accumulates compliance debt as it grows.

Payments, as an industry, are moving toward a state where stablecoin rails are broadly available. As a result, performance will be roughly equivalent across leading providers.

In that market, compliance infrastructure is what separates the providers that scale from the ones that stall. That’s what payment operators will increasingly use to evaluate infrastructure partners.

Dakota's compliance architecture is embedded at the transaction level, modular by design, and built to adapt as regulatory requirements evolve. For businesses operating across multiple jurisdictions, Dakota is the foundation that makes global, programmable payments reliable in production.



The Compliance Stack Is the Product Now

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

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. 

Blog.

Dakota Applies for a National Trust Bank Charter

Earlier posts

Tell us what you’re building.