How ndStill works

A control plane that lets AI agents spend from your accounts, inside strict guardrails.

The bank accounts are yours. Your AI agents are capped delegates allowed to spend from them: each payment is checked, unusual ones come to you, and everything lands in a permanent log. ndStill stands between agents and bank and applies your rules to each action.

No way around it

The gateway checks every limit on the server. An agent has no path past them.

You keep the final say

Risky or unclear actions pause until a person approves. ndStill never holds your funds.

Two rails

Each org picks one at creation: Increase (US), or India, which has no banking partner live yet.

Reading the gate strip

In the console, each transfer carries a strip of nine blocks: one per check, in the order they run. This one passed five checks and is held at the sixth, caps and limits.

The nine checks are listed under transfer checks.

ndStill is a single chain of layers. Spending moves down it; oversight moves up. People often mix up “connection” and “account”. The layers below keep them apart:

1. Owner (you)the person

   The verified person or business. Owns the bank relationship and the funds, and approves risky transfers.

   ↓ links
2. Bank connectionthe rail

   One rail per org, US or India. It gives access to your bank; it is not money by itself.

   ↓ contains
3. Org accounts (1..N)the balance

   Real bank accounts on that rail. Balances are read live from the rail, and spending comes out of them.

   ↓ drawn on by
4. Agentsspend within caps

   AI agents allowed to spend from your accounts, up to the caps you set. They have caps, not balances.

Org

Your workspace. Contains accounts, agents, policies and members. Its single rail is fixed at creation.

Connection

Encrypted rail credentials for your org. There is one per org, managed under Bank connection.

Account

A real bank account agents spend from: an Increase account in the US, or an India corporate or virtual account. Each org has at least one.

Agent

An AI agent registered with an API key. It spends from org accounts up to its caps and holds no funds.

Policy

The rules for one agent: per-transfer limit, approval threshold, window caps, MCC allow/block, anomaly settings.

Account access

The accounts an agent may draw on, plus a default. Leave it empty to allow every org account.

Guardrail

A check the server runs on each transfer. Pass → it sends; fail → it is held or refused.

Approval

A held transfer waiting on a person to approve or reject. It plays the role an “OTP” would.

Beneficiary

A saved payee. On the India rail, you must add one before paying that recipient.

Audit log

A tamper-proof, add-only history of every action that matters.

Kill switch

Freeze one agent or all of them at once. A frozen agent can’t move money.

API key

The credential, scoped to one agent, that it sends to ndStill over MCP or HTTP.

Every account is a real bank account, and ndStill never holds the funds. The rail decides how you add one:

US · IncreaseSandbox key today

ndStill uses Increase’s API to open a new real account (POST /accounts) with its own account and routing number (/account_numbers). Set up a separate “agent ops” account, put a set amount in it, and let agents spend only from there.

India

Register a corporate account you already hold; that works today. Per-agent virtual account numbers, payouts and balances need a banking partner, and none is wired yet, so those calls return an error. Funds always stay at the bank.

An agent has no wallet and no balance. It’s an identity made of an API key, a policy (its caps), and an access list (the accounts it may use). Funds stay at the bank; ndStill keeps the agent inside its limits.

Caps (policy)

Per-transfer limit, approval threshold, daily/weekly/monthly caps, MCC allow/block, anomaly settings.

Account access

Pick certain accounts (say, just “Procurement”), or allow every org account. One is set as its default.

Identity

A unique agent id and a scoped API key. Each call is checked against the key and the access list.

Freeze

Freeze one agent, or all, in one step. While frozen, each of its transfers is blocked.

Each transfer request passes these checks one after another. Any of them can stop it. Pick an example to see how a transfer looks at each check.

Sent

Every check passes. ndStill sends it on the rail (an Increase transfer in the US; India payouts need a partner first) and the account is debited. Returns SUCCESS.

Held

A rule fires. Nothing is sent. Returns PENDING_APPROVAL, and the transfer waits in your Approvals inbox.

Per-transaction limit

Largest amount one transfer may be. Above it → held.

Approval threshold

Transfers at or above this amount always wait for a person.

Window limits

Rolling daily, weekly and monthly spend caps for each agent.

LLM confidence floor

The agent sends a confidence score; under the floor → held.

Anomaly (velocity)

Many transfers in a short time → held automatically.

Anomaly (spike)

An amount well above the agent's recent average → held.

MCC allow/block

Card only: the merchant categories an agent may pay.

Hard platform cap

A platform ceiling no policy can raise. The final safety net.

Set every threshold per agent, on the agent’s caps in the console. The defaults start strict.

Held transfers wait in Approvals, each with the reason it was held. Approve sends it; reject cancels it for good. Agents can’t answer an OTP, so this human decision takes that place, and ndStill asks for it only when the stakes are high.

The India rail is built to give each agent a Virtual Account Number: its own account identifier under your corporate account, so each payment traces to one agent. Creating VANs errors until a banking partner is wired; the design is below.

One per agent

A separate account number for each agent or team, so matching and reconciling payments is simple.

Caps still apply

The gateway checks each agent's caps and limits, exactly as on the US rail, with no way around them.

Worth knowing

• A VAN is a label, not a separate pot of money: each one points to your single corporate account, so the balance stays in one visible place.
• Payouts leave from that corporate account; ndStill tags each with its agent and keeps every agent within its caps.

On Increase, you can give an agent single-use virtual cards backed by an org account. When the card is used, Increase asks ndStill in real time: ndStill checks the card limit and the agent’s MCC allow/block policy, approves or declines, and logs the charge with its category for spend reporting. Cards exist on the US rail only; India uses transfers.

1. You fund an account
2. Agent spends, within caps

   ndStill checks caps
3. Recipient gets paid

You put a set amount into a real account. Agents ask to pay; ndStill checks each request against that agent’s caps and sends the allowed ones on the rail from that account. Funds never pass through ndStill.

Audit log

Add-only, enforced in the database (UPDATE/DELETE blocked). Search it, filter by date, export CSV.

Kill switch

Freeze one agent or every agent at once, as soon as something seems off.

Anomaly monitor

Bursts and sudden large amounts are held for review, using per-agent thresholds.

Agents call ndStill through the MCP server (Cursor / Claude Desktop) or plain HTTP. Each call sends the agent’s API key in the X-API-Key header.

Create a transfer

curl -X POST "$NDSTILL_GATEWAY_URL/v1/transfers" \
  -H "X-API-Key: $NDSTILL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "agent_id": "procurement-bot",
    "recipient_account_id": "acct_x",
    "amount_in_cents": 4000,
    "llm_confidence_score": 0.86,
    "source_account_id": "<optional org account>"
  }'

{ "status": "SUCCESS" }            // executed on the rail
{ "status": "PENDING_APPROVAL" }   // held for a human

To try a transfer without moving money, add "simulate": true (or call ndstill_simulate_transfer). Every check runs, nothing is sent and no transfer is saved; the response gives would_status and a trace of the checks.

MCP tools

ndstill_transfer, ndstill_simulate_transfer, ndstill_list_accounts, ndstill_create_wallet, ndstill_list_transfers, and tools for policies and cards.

Keys

Create keys on the API keys page. Each key belongs to exactly one agent in one org.

ndStill starts with the US (Increase) and India rails, and the core does not depend on any one rail. Your agent code and guardrails stay the same as new markets are added, so an integration you write now keeps working in each new country.

More markets

After the US and India: the UK, the EU and more of Asia, one banking partner at a time, on the same API.

More rails and methods

Extra bank partners, local payment networks and account types as each market is added.

More agent abilities

Recurring payments, multi-step workflows and marketplace connectors, all under the same controls.

Integrate once

Build against ndStill one time, then add countries without new work for each rail.