Jump to main content
ndStill

ndStill, step by step

Bank rail → accounts → agents. Spending runs down the chain; oversight runs back up.

Set up your org

Five steps, by you, one time. Steps 2 and 3 are not the same: linking the rail reaches your bank; adding an account gives agents something to spend from.

  1. 1Complete KYC

    Confirm who owns the org. Agents act on your behalf, so they skip KYC.

  2. 2Link your bank rail

    Pick the US or India rail. This lets ndStill talk to your bank; it moves no money on its own.

  3. 3Add an account

    Open a new account (US), or register one you already hold by number and IFSC (India). Agents spend from these.

  4. 4Create an agent

    Give it a per-transfer limit, an approval threshold, and the accounts it may use. It cannot go past them.

  5. 5Create an API key

    Issue a key scoped to one agent, then give it to that agent for MCP or direct API calls.

    Then point the agent’s MCP client (Cursor, Claude Desktop) at ndStill with its key:

    MCP config
    {
  "mcpServers": {
    "ndstill": {
      "command": "python3",
      "args": ["/path/to/ndstill/mcp/server.py"],
      "env": {
        "NDSTILL_GATEWAY_URL": "<gateway url>",
        "NDSTILL_API_KEY": "<agent key>",
        "NDSTILL_ORG_ID": "<your org id>"
      }
    }
  }
}

How the pieces fit

You own the accounts. Agents are capped delegates. A person approves the risky ones. ndStill never holds funds.

Your bankthe rail link
Link one rail per org: Increase in the US, or India (no banking partner live yet). It grants access, not money. ndStill never holds your funds.
Org accountsholds the balance
On that rail you open or register one or more real accounts. Balances sit here, live from the rail, and spending draws from them.
Agentsspend within caps
An agent has no account of its own. It may spend from the accounts you allow, and never past the caps you give it.

Day to day

The agent

  • 1
    Requests a transferIt sends POST /v1/transfers with its own key. It may pick a source account; if not, ndStill uses its default.
  • 2
    Guardrails decideInside the caps → sent on your rail from that account. Over a limit, unusual, or low confidence → held for approval.

You

The request an agent sends

HTTP
POST /v1/transfers
X-API-Key: <agent key>
{
  "agent_id": "procurement-bot",
  "recipient_account_id": "acct_x",
  "amount_in_cents": 4000,
  "llm_confidence_score": 0.86,
  "source_account_id": "<optional org account>"
}

→ SUCCESS            // sent on the rail
→ PENDING_APPROVAL   // held for a person
  • Let an agent use every org account, or limit it to the ones you pick.
  • The gateway enforces caps, so an agent can’t get around them.
  • Sudden bursts or unusually large amounts pause for your approval.
  • Virtual cards are US only; India uses NEFT/RTGS/IMPS transfers.

Every field, the MCP tools and test mode are in the reference.

Let your agents spend from your own accounts.

Create accountSign in