Connect Dwolla to ChatGPT: Automate Identity Verification & Payments

If you need to automate ACH transfers, orchestrate identity verification (KYC), or manage beneficial ownership data directly through natural language, you need to connect Dwolla to ChatGPT. You do this using a Model Context Protocol (MCP) server. If your team uses Claude, check out our guide on connecting Dwolla to Claude or explore our broader architectural overview on connecting Dwolla to AI Agents.

Giving a Large Language Model (LLM) read and write access to a financial platform like Dwolla is an intense engineering challenge. Moving money programmatically requires strict adherence to schema definitions, exact reference mapping, and flawless execution. You either spend weeks building, hosting, and maintaining a custom MCP server, or you use a managed infrastructure layer that handles the boilerplate for you. This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Dwolla, connect it natively to ChatGPT, and execute complex payment workflows using natural language.

The Engineering Reality of Custom Dwolla Connectors

A custom MCP server is a self-hosted integration layer that translates an LLM's tool calls into REST API requests. While Anthropic's open standard provides a predictable way for models to discover tools, the reality of implementing it against vendor APIs is painful. If you decide to build a custom MCP server for Dwolla, you are responsible for the entire API lifecycle. Dwolla is not a standard CRUD API. It has highly specific architectural patterns that break generic integration tools.

The HAL+JSON Hypermedia Constraint

Dwolla uses the HAL (Hypertext Application Language) format for its JSON responses. Instead of passing flat foreign keys (e.g., funding_source_id: "123"), relationships are defined via _links objects containing URIs. When an LLM wants to create a transfer, it cannot simply provide a source and destination ID. It must construct a nested object pointing to the exact hypermedia links of those resources:

{
  "_links": {
    "source": {
      "href": "https://api.dwolla.com/funding-sources/123"
    },
    "destination": {
      "href": "https://api.dwolla.com/funding-sources/456"
    }
  },
  "amount": {
    "currency": "USD",
    "value": "100.00"
  }
}

LLMs are notoriously bad at correctly formatting these nested, specialized objects without immense schema guidance. A custom MCP server must map standard parameters into this HAL structure on the fly.

KBA Array Strictness

During the KYC process, initiating Knowledge-Based Authentication (KBA) requires fetching dynamic questions and posting an array of exactly four question-answer pairs back to Dwolla. If an LLM hallucinates a format, misses a required questionId, or provides a string instead of the expected object array, the identity verification fails, locking the customer account.

Rate Limits and 429 Errors

Dwolla enforces strict rate limits to protect financial infrastructure. If your AI agent gets stuck in a loop or attempts to paginate through 10,000 transaction records simultaneously, Dwolla will return a 429 Too Many Requests error. Factual note on rate limits: Truto does not retry, throttle, or apply backoff on rate limit errors automatically. When Dwolla returns HTTP 429, Truto passes that error directly to the caller and normalizes the upstream rate limit info into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF spec. The calling orchestrator - your agent framework - is strictly responsible for implementing retry and exponential backoff logic.

The Managed MCP Approach

Instead of forcing your engineering team to build a custom API mapping layer, Truto's MCP servers turn any connected Dwolla instance into a standardized, AI-ready toolset.

Tool generation in Truto is dynamic and documentation-driven. Rather than hand-coding tool definitions for every Dwolla endpoint, Truto derives them from the integration's resource definitions and human-readable documentation records. The query and body schemas are automatically extracted, injected with cursor pagination context, and translated into JSON Schema. The LLM receives a flat input namespace, and Truto's underlying proxy API handles the complex HAL+JSON translations before sending the request to Dwolla.

Each server is scoped to a single integrated account. The server URL contains a cryptographic token that authenticates the request and scopes the available tools based on your defined filters.

Creating the Dwolla MCP Server

You can generate an MCP server for Dwolla using either the Truto UI or the API. Both methods result in a secure, token-backed URL that you will provide to ChatGPT.

Method 1: Via the Truto UI

1. Log into your Truto dashboard and navigate to the integrated account page for your Dwolla connection.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Select your desired configuration. For financial applications, you often want to isolate operations. You might configure one server to allow only methods: ["read"] for account querying, and another specifically tagged for ["payments"].
5. Copy the generated MCP server URL (e.g., https://api.truto.one/mcp/a1b2c3d4e5f6...).

Method 2: Via the Truto API

For automated deployments, you can programmatically provision MCP servers by making a POST request to the Truto API. The API validates that Dwolla tools are available, stores the hashed token in a highly available key-value store, and returns the URL.

Endpoint: POST /integrated-account/:id/mcp

curl -X POST https://api.truto.one/integrated-account/YOUR_ACCOUNT_ID/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Dwolla Agent Server",
    "config": {
      "methods": ["read", "create", "update"]
    },
    "expires_at": "2026-12-31T23:59:59Z"
  }'

Connecting the MCP Server to ChatGPT

Once you have your Truto MCP URL, connecting it to ChatGPT takes under a minute. You can do this directly through the interface or via an SSE connection for local setups.

Option A: Via the ChatGPT UI

1. Open ChatGPT and navigate to Settings -> Apps -> Advanced settings.
2. Enable Developer mode (custom MCP support is located behind this toggle).
3. Under MCP servers / Custom connectors, click to add a new server.
4. Name: "Dwolla Operations"
5. Server URL: Paste the Truto MCP URL.
6. Click Add.

ChatGPT will immediately handshake with the URL, exchange capabilities, and list the available Dwolla tools. If you configured require_api_token_auth: true during creation, you will need to add your Truto API key as a Bearer token in the headers interface.

Option B: Via Manual Config File

If you are running an orchestrator that relies on standard MCP client configurations, you can use the Server-Sent Events (SSE) transport. Create a configuration file pointing to the Truto endpoint:

{
  "mcpServers": {
    "dwolla-mcp": {
      "command": "npx",
      "args": [
        "@modelcontextprotocol/server-sse",
        "--url",
        "https://api.truto.one/mcp/YOUR_SECURE_TOKEN"
      ]
    }
  }
}

Dwolla Hero Tools for ChatGPT

Once connected, ChatGPT has access to the Dwolla REST API abstracted as discrete tools. The MCP router splits the LLM's flat arguments into the required query and body schemas. Here are the core tools your agent will use to orchestrate financial operations.

create_a_dwolla_customer

Creates a new Dwolla customer record. This tool handles unverified customers, personal verified customers, business verified customers, and receive-only users. The schema automatically requires the correct identity parameters based on the customer type requested.

"I have a new vendor named Acme Corp. Create a business verified customer record for them in Dwolla using the email billing@acmecorp.com."

create_a_dwolla_customer_funding_source

Creates a bank account or debit card funding source for a specific customer. It supports manual entry with routing and account numbers or open banking linkages. The LLM handles passing the customer ID and the routing data.

"Link a new checking account to customer ID 8123-abcd as a funding source. The routing number is 123456789 and the account number is 987654321. Name it 'Primary Checking'."

create_a_dwolla_transfer

Initiates a transfer between funding sources. It supports ACH, Instant Payments (RTP/FedNow), Push-to-Debit, and wire transfers. The tool abstracts the difficult HAL+JSON linking, allowing the LLM to simply provide the source ID, destination ID, and amount.

"Initiate an ACH transfer of $450.00 from my main operating account funding source to the vendor's checking account funding source."

list_all_dwolla_mass_payments

Lists mass payments created by a Dwolla account. Returns a paginated list of mass payment objects containing up to 5,000 individual payment items. Crucial for auditing batch payout operations.

"Pull the status of all mass payments processed this week for the main account. Are any of them currently marked as failed?"

create_a_dwolla_customer_kba

Initiates a Knowledge-Based Authentication session for a personal Verified Customer who failed initial identity verification. It retrieves the KBA identifier needed to present questions to the end user.

"Customer ID 456-def was suspended during KYC. Initiate a KBA session for them and return the authentication questions so I can relay them to the user."

list_all_dwolla_customers

Lists and searches Dwolla customers across the platform. It supports fuzzy search across names and exact filtering by email or verification status. Essential for discovery before taking action on an account.

"Search for all customers with the 'document' verification status. We need to find users who still need to upload their passports."

For the complete inventory of available tools, required properties, and JSON schemas, view the Dwolla integration page.

Workflows in Action

By chaining these generated tools together, ChatGPT can act as a fully autonomous payment operations assistant. Here is how complex workflows play out in practice.

Workflow 1: Resolving a KYC Suspension

Financial platforms require constant KYC maintenance. When a user fails automatic verification, an agent can take over to initiate document uploads or KBA.

"Check our Dwolla customers for anyone currently in a suspended state. If you find one, lookup their details and initiate a KBA session to get the challenge questions."

1. list_all_dwolla_customers: The agent calls this tool with a query parameter filtering for the suspended verification status.
2. get_single_dwolla_customer_by_id: The agent extracts the ID from the previous response and retrieves the specific user details.
3. create_a_dwolla_customer_kba: The agent executes this tool against the customer ID, receiving a payload of four multiple-choice identity questions, which it formats clearly in the chat window.

flowchart TD
    User["User Prompt"] --> A
    A["list_all_dwolla_customers<br>filter: suspended"] --> B
    B["get_single_dwolla_customer_by_id"] --> C
    C["create_a_dwolla_customer_kba"] --> Output["Agent presents KBA questions"]

Workflow 2: Investigating a Failed Transfer

When a vendor complains they haven't been paid, customer support teams usually have to open an engineering ticket. With an MCP server, the agent can trace the money directly.

"A vendor with the email 'supplies@acmecorp.com' said they never received their $1,200 payment. Find their customer record, locate their transfers, and tell me why the transaction failed."

1. list_all_dwolla_customers: The agent searches by the provided email address to find the vendor's exact Dwolla ID.
2. list_all_dwolla_customer_transfers: Using the ID, the agent requests the transfer history, applying a filter for the $1,200 amount.
3. Analysis: The agent reads the response, identifies that the transfer status is "failed", and reads the failure reason (e.g., "R01 Insufficient Funds" on the sender's side). It summarizes the exact banking error to the user without hallucinating.

Security and Access Control

Exposing a payment API to an LLM requires strict boundary setting. Truto's MCP servers manage scope directly at the token layer, ensuring the model cannot override permissions through prompt engineering.

• Method Filtering: Configure config.methods: ["read"] to strictly limit the server to get and list operations. The integration will reject any attempts to create a transfer or update a funding source.
• Tag Filtering: Group specific operations (e.g., tagging KYC operations with ["compliance"]). You can restrict the MCP server so it only exposes tools with those specific tags.
• Extra Authentication: By setting require_api_token_auth: true, possession of the MCP URL is no longer sufficient. The caller must also pass a valid Truto API token in the headers, adding a secondary defense layer for sensitive financial tools.

If you want to stop building boilerplate JSON schemas, handling OAuth refreshes, and writing backoff loops for every third-party vendor, a managed infrastructure layer is the right architectural choice.