Connect Orum to Claude: Manage Payments and Business Customers

If you need to connect Orum to Claude to automate B2B payments, manage subledgers, verify business identities, or track complex financial operations, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's function calling capabilities and Orum's highly regulated REST APIs. You can either build and maintain this financial infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL. If your team uses ChatGPT, check out our guide on connecting Orum to ChatGPT or explore our broader architectural overview on connecting Orum to AI Agents.

Giving a Large Language Model (LLM) read and write access to a core payment infrastructure like Orum is a high-stakes engineering challenge. You have to handle strict API token lifecycles, map complex financial JSON schemas to MCP tool definitions, and deal with Orum's strict idempotency requirements. Every time Orum updates a payment rail or introduces a new compliance field, you have to update your server code, redeploy, and rigorously test the integration.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Orum, connect it natively to Claude Desktop, and execute complex treasury and payment workflows using natural language.

The Engineering Reality of the Orum API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools over JSON-RPC, the reality of implementing it against a highly specialized financial API like Orum is painful. Orum is built to route funds across ACH, RTP, FedNow, and wire transfers. Its API reflects the uncompromising realities of the banking system.

If you decide to build a custom Orum MCP server, here are the specific integration challenges you will face:

Strict Idempotency and Reference IDs Unlike a CRM where creating a contact simply returns an auto-incrementing ID, Orum relies entirely on client-provided reference IDs (e.g., transfer_reference_id, customer_reference_id, subledger_reference_id). This is crucial for idempotency to ensure funds aren't moved twice during network retries. An LLM has no inherent concept of UUID generation or tracking which reference IDs it has already used. Your MCP middleware must either enforce UUID generation for the LLM or provide explicit schema instructions on how the agent should construct unique idempotency keys.

Asynchronous Payment Rails and State Machines When you initiate a transfer in Orum, the API does not synchronously return a "success" state. It returns a pending status. The actual settlement of funds - or a rejection due to Non-Sufficient Funds (NSF) - happens asynchronously, sometimes days later in the case of standard ACH. LLMs operate synchronously in a request/response paradigm. If an agent tries to verify a transfer succeeded immediately after creating it, it will fail. Your architecture must bridge this gap, often requiring the LLM to either poll a get_single_orum_deliver_transfer_by_id tool or rely on a separate webhook ingestion pipeline that updates an external database the LLM can read.

Rate Limits and 429 Handling Financial APIs enforce strict concurrency and rate limits to prevent abuse. It is critical to note that Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream Orum API returns an HTTP 429, Truto passes that error directly back to the caller. Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF spec. The MCP client (in this case, the framework executing Claude's tool calls) is entirely responsible for detecting the 429 and applying its own retry and exponential backoff logic.

Generating a Managed Orum MCP Server

Instead of building a JSON-RPC server from scratch, handling Orum's schema extraction, and writing middleware to enforce token expiration, you can use Truto. Truto dynamically generates an MCP server for any connected Orum account.

Truto derives MCP tools directly from Orum's API documentation and endpoint definitions. It automatically translates Orum's query parameters and JSON body payloads into MCP-compliant schemas, injecting helpful descriptions that guide Claude on how to use idempotency keys and handle Orum's strict validation rules.

You can generate the Orum MCP server using two methods: the Truto UI for manual configuration, or the Truto API for programmatic provisioning.

Method 1: Via the Truto UI

If you are provisioning access for an internal operations team, the UI is the fastest path.

1. Log in to your Truto dashboard and navigate to the integrated account page for your connected Orum instance.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Select your desired configuration. You can filter the server to only expose read methods (to prevent accidental transfers) or filter by specific tags like deliver or verify.
5. Click Save, and copy the generated MCP server URL (e.g., https://api.truto.one/mcp/a1b2c3d4e5f6...).

Method 2: Via the Truto API

For platforms building multi-tenant AI agents, you can programmatically generate MCP servers for your end-users. When you make a POST request to /integrated-account/:id/mcp, Truto validates the Orum connection, generates a cryptographically hashed token, stores it in distributed edge storage, and returns a ready-to-use URL.

// POST /integrated-account/:id/mcp
const response = await fetch('https://api.truto.one/integrated-account/act_8f9e.../mcp', {
  method: 'POST',
  headers: {
    'Authorization': 'Bearer YOUR_TRUTO_API_KEY',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    name: "Orum Treasury MCP",
    config: {
      methods: ["read", "write"],
      tags: ["transfers", "businesses"]
    },
    expires_at: "2026-12-31T23:59:59Z"
  })
});
 
const mcpServer = await response.json();
console.log(mcpServer.url); 
// Output: https://api.truto.one/mcp/a1b2c3... 

Connecting the Orum MCP Server to Claude

Once you have your Orum MCP URL, you need to connect it to Claude. Because Truto's MCP servers are fully self-contained - meaning the URL itself contains the routing and authentication token for that specific Orum account - the client configuration is trivial.

Method 1: Via the Claude UI

If you are using the Claude desktop app or web interface on an eligible plan, you can add the server directly through the settings.

1. Copy your generated MCP server URL from Truto.
2. In Claude, navigate to Settings -> Integrations -> Add MCP Server.
3. Paste the URL and click Add.

Claude will immediately perform a JSON-RPC handshake (initialize) with the Truto MCP router, request the list of Orum tools (tools/list), and ingest the schemas.

Method 2: Via Manual Configuration File

If you are using Claude Desktop in a developer environment or orchestrating Claude via an SDK that reads standard MCP configuration files, you will use the @modelcontextprotocol/server-sse transport.

Edit your claude_desktop_config.json file (typically located at ~/Library/Application Support/Claude/claude_desktop_config.json on macOS or %APPDATA%\Claude\claude_desktop_config.json on Windows):

{
  "mcpServers": {
    "orum-treasury": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/a1b2c3d4e5f6..."
      ]
    }
  }
}

Save the file and restart Claude Desktop. The Orum tools are now available for function calling.

Essential Orum MCP Tools for Claude

Truto automatically generates snake_case tools from the Orum API documentation. When Claude calls a tool, the Truto MCP Router splits Claude's flat argument object into the correct query parameters and request bodies expected by Orum, executes the request against Orum's API, and returns the normalized JSON payload.

Here are the hero tools for managing Orum operations.

create_a_orum_deliver_business

This tool creates a business customer in Orum. It is the required first step before you can attach external accounts or initiate transfers on behalf of a corporate entity. The LLM must generate a unique customer_reference_id.

"I need to onboard a new business entity named 'Acme Corp'. Generate a unique customer reference ID for them and create the business profile in Orum. Then confirm the status of the new profile."

create_a_orum_external_account

This tool attaches an external bank account to an existing person or business in Orum. It requires routing and account numbers, and must be linked using the customer_reference_id generated in the previous step.

"Take the customer reference ID we just created for Acme Corp. Attach their corporate checking account ending in 1234, routing number 021000021, and name the account holder 'Acme Corporate Account'. Return the new account reference ID."

create_a_orum_verify_account

Before you can pull funds from an external account, Orum often requires account verification. This tool submits bank details to Orum's verification engine to determine ownership and control status.

"Submit the Acme Corp external account details to the Orum Verify service. Let me know if the verification status comes back as approved or if it requires micro-deposits for manual verification."

list_all_orum_deliver_eligibilities

This tool allows the agent to check if a specific routing number is eligible for instant payment rails like RTP (Real-Time Payments) and FedNow. This is crucial for routing logic.

"Check if routing number 021000021 is eligible for FedNow or RTP. If it is, we will route the upcoming transfer via the fastest available instant rail. If not, we will default to standard ACH."

create_a_orum_deliver_transfer

This is the core tool for moving money. It initiates a transfer between a source and destination. The LLM must provide a unique transfer_reference_id, the amount, currency, and the desired speed (e.g., same_day, next_day, rtp).

"Initiate a $5,000 transfer from our main enterprise balance to Acme Corp's verified external account. Generate a unique transfer reference ID. Set the speed to same_day. Return the transfer ID and the estimated funds delivery date."

get_single_orum_deliver_transfer_by_id

Because transfers are asynchronous, this tool is used to check the status of a specific transfer ID. It allows the agent to monitor a pending transaction to see if it has moved to a settled or failed state.

"Check the status of the $5,000 transfer we initiated to Acme Corp using the Orum transfer ID. Let me know if the status is still pending or if it has encountered any status reasons or errors."

create_a_orum_deliver_subledger

Subledgers allow you to segregate funds virtually under a single enterprise account. This tool creates a subledger tied to a specific customer, enabling complex escrow, FBO (For Benefit Of), or digital wallet architectures.

"Create a new subledger for customer reference ID 'acme_corp_123'. Assign it a unique subledger reference ID. This will act as their dedicated virtual wallet for incoming payments."

Note: This is just a selection of high-leverage operations. For the complete Orum tool inventory, including schedule management, webhooks, and reporting tools, check the Orum integration page.

Workflows in Action

With the MCP server connected to Claude, you can orchestrate complex, multi-step financial operations using natural language prompts. Truto handles the schema mapping, while Claude manages the logic and tool sequencing.

Scenario 1: Intelligent Payment Routing (Treasury Operations)

Corporate treasury teams need to route payments dynamically based on rail availability to optimize for speed and cost.

The Prompt:

"We need to send a $12,500 payout to Vendor XYZ (customer reference ID: vendor_xyz_88). First, find their active external account. Then, check if their bank's routing number is eligible for FedNow. If it is, execute the transfer using the FedNow speed rail. If not, fallback to Next Day ACH. Generate a unique transfer reference ID and confirm the final execution status."

Step-by-Step Execution:

1. Claude calls list_all_orum_business_external_accounts passing business_id: vendor_xyz_88 to retrieve the routing number.
2. Claude calls list_all_orum_deliver_eligibilities passing the extracted routing number to check FedNow support.
3. Claude evaluates the boolean response for FedNow eligibility.
4. Claude calls create_a_orum_deliver_transfer using a generated UUID for transfer_reference_id, setting amount: 12500, and dynamically setting the speed parameter based on step 3.

The Result: The user receives a natural language confirmation of the routing decision, along with the Orum-generated transfer ID and the estimated delivery date based on the chosen payment rail.

sequenceDiagram
  participant Claude as Claude Desktop
  participant Truto as Truto MCP Server
  participant Orum as Orum API
  Claude->>Truto: call_tool("list_all_orum_deliver_eligibilities")
  Truto->>Orum: GET /deliver/routing_numbers/eligibility
  Orum-->>Truto: { eligible: true }
  Truto-->>Claude: JSON response
  Claude->>Truto: call_tool("create_a_orum_deliver_transfer")
  Truto->>Orum: POST /deliver/transfers
  Orum-->>Truto: 201 Created (speed: fednow)
  Truto-->>Claude: JSON response

Scenario 2: Multi-Entity Onboarding and Subledger Provisioning

Fintech platforms often need to onboard businesses, attach funding sources, and provision virtual ledgers in a specific sequence.

The Prompt:

"Onboard a new marketplace seller named 'Global Imports LLC'. Generate a unique customer reference ID. Once the business profile is created, provision a dedicated subledger for them so we can track their balances. Return the customer ID and the subledger ID in a formatted table."

Step-by-Step Execution:

1. Claude generates a string like global_imports_uuid.
2. Claude calls create_a_orum_deliver_business with the generated customer_reference_id and the legal_name "Global Imports LLC".
3. Claude extracts the internal Orum id for the new business.
4. Claude generates a new string for subledger_reference_id.
5. Claude calls create_a_orum_deliver_subledger mapping the customer_reference_id to the new business.

The Result: Claude outputs a clean markdown table containing the new Orum IDs. It successfully navigated the strict relational hierarchy (Business -> Subledger) without the user having to write a single line of orchestration code.

Security and Access Control

Giving an AI model access to a payment infrastructure like Orum requires strict security guardrails. Truto provides multiple layers of access control at the MCP server level, ensuring agents can only perform authorized actions.

• Method Filtering: You can restrict the MCP server to only allow read operations (like get and list). This is ideal for analytics agents that need to report on balances and transfer statuses, mathematically ensuring the LLM cannot initiate a transfer or mutate records.
• Tag Filtering: Orum tools can be restricted by tags. You can create an MCP server that only exposes verify tools, hiding all deliver (money movement) endpoints from the LLM.
• Require API Token Auth: By enabling require_api_token_auth: true, possession of the MCP URL is no longer sufficient. The Claude client must also pass a valid Truto API token in the Authorization header, adding a secondary identity check.
• Time-to-Live (TTL): Using the expires_at parameter, you can create ephemeral MCP servers. The server automatically destroys itself at the specified timestamp, which is perfect for temporary agent sessions handling sensitive financial investigations.

Wrapping Up

Connecting Claude to Orum transforms a static chat interface into a dynamic treasury management system. By using Truto's managed MCP servers, you bypass the massive engineering overhead of maintaining financial API integrations, handling complex schema conversions, and building custom JSON-RPC middleware.

Instead of reading API docs and writing idempotency logic, your team can focus on designing the prompts and workflows that actually automate your Orum payment operations.