API to Validate Routing Number 114000093

You need to confirm that routing number 114000093 is valid and belongs to the expected bank before sending an ACH transfer or onboarding an account. By the end of this guide, you’ll validate that ABA routing number via the BankDataStack API, read the returned bank details, and wire it into your payments or compliance workflow with clear error handling and caching.

What routing number 114000093 represents in ACH payments

Routing numbers are nine-digit ABA identifiers used by U.S. financial institutions to route ACH and check transactions. The specific number 114000093 is issued to Frost Bank, and is marked as active. When you validate this routing number through BankDataStack, you also get the bank name, branch type, and mailing address you can show to operators or use to auto-fill counterparty details.

For ACH payments, confirming both the checksum and the institution details helps prevent misroutes and reduces returns. It also gives your risk and ops teams a verifiable source of truth that they can log in your audit trail.

ABA routing format and checksum at a glance

A U.S. routing number is 9 digits. The last digit is a check digit validated by a weighted sum. At a high level:

• Digits are weighted in repeating groups of 3, 7, and 1.
• Multiply each digit by its weight and sum the results.
• A valid routing number has a sum that is a multiple of 10 (sum mod 10 equals 0).

This checksum catches most common keying errors (transposed digits, single-digit mistakes). However, even a valid checksum does not guarantee the number is active or associated with the expected bank, which is why a directory lookup is necessary.

Validate 114000093 with the API

Use the routing validation endpoint to check 114000093 for ACH. The request accepts a routing number and an optional payment type field to align your validation to a specific rail (ACH shown below). Keep your API key in an environment variable and send it as a header.

cURL example

curl -X POST "https://www.bankdatastack.com/api/v1/routing/validate" -H "X-API-Key: YOUR_API_KEY" -H "Content-Type: application/json" -d '{"routing_number":"114000093","payment_type":"ach"}'

Python example

import os
import json
import requests

API_KEY = os.getenv("BANKDATASTACK_API_KEY", "YOUR_API_KEY")
url = "https://www.bankdatastack.com/api/v1/routing/validate"

payload = {
"routing_number": "114000093",
"payment_type": "ach"
}

headers = {
"X-API-Key": API_KEY,
"Content-Type": "application/json",
}

resp = requests.post(url, headers=headers, data=json.dumps(payload), timeout=10)
resp.raise_for_status()
data = resp.json()

# Basic checks you might do in a payments flow
if data.get("status") != "success":
raise ValueError("Lookup failed, do not proceed with payment.")

bank = data.get("data", {})
if not bank.get("active", False):
raise ValueError("Routing number is not active for ACH.")

# Log or display the minimal details needed for operator verification
print({
"routing_number": bank.get("routingNumber"),
"bank_name": bank.get("name"),
"branch_type": bank.get("type"),
"address": bank.get("addressFull"),
"phone": bank.get("phone"),
"last_updated": bank.get("lastUpdated"),
})

What the API returns for 114000093

Below is the live sample response for this routing number. You can use these fields to verify the bank name and location against customer-provided paperwork, to autofill onboarding forms, and to log the authoritative source in your audit logs.

{
    "status": "success",
    "data": {
        "routingNumber": "114000093",
        "paymentType": "ach",
        "name": "Frost Bank",
        "addressFull": "2735 Austin Hwy, San Antonio, TX 78218",
        "street": "2735 Austin Hwy",
        "city": "San Antonio",
        "state": "TX",
        "zip": "78218",
        "type": "Main Office",
        "phone": "888-481-0336",
        "active": true,
        "lastUpdated": "2026-11-10",
        "address": "2735 AUSTIN HWY"
    }
}

How to use these fields in your flow:

• routingNumber and paymentType: confirm that your ACH flow is referencing the exact identifier and rail you validated.
• name, type: display “Frost Bank – Main Office” to your ops team or end users for confirmation.
• addressFull (plus street/city/state/zip): auto-fill bank address in KYB/KYC forms or internal records.
• active: block payments or onboarding if false; allow if true.
• phone: useful for manual callbacks if your ops process requires bank verification.
• lastUpdated: record data freshness in logs; use it to inform your cache TTL.

Integrating validation into payment and onboarding flows

Most teams add routing lookups at two points: when collecting bank details from a counterparty, and when preparing to submit an ACH file. Here’s a simple pattern you can adopt:

1. At bank account entry (UI): after the user types nine digits, run a client-to-server call that proxies to the BankDataStack validation. Confirm checksum and fetch the bank name for display. Only store the routing number and bank metadata you need for the payment.
2. At payment execution: re-validate the routing number if your cache is stale or missing, confirm active is true, and ensure the paymentType you’re submitting (ach) matches the validated type.
3. In your ops console: show bank name, branch type, address, and lastUpdated alongside each payment or counterparty for faster reviews.

For ACH returns and disputes, audit logs should include the validation response snippet (status, bank name, lastUpdated) and the time you performed the check. This is particularly helpful for compliance and vendor management reviews.

Handling “not found,” inactive results, and timeouts

Not found: this usually indicates one of the following:

• A typographical error (checksum failure or miskeyed digits).
• An unassigned or retired routing number.
• A paymentType mismatch for the rail you requested.

In all of these cases, do not proceed with the payment. Prompt the user to re-check the number, or escalate to an operator for manual review.

Inactive: some routing numbers are present in directories but not active for the rail you’re using. When active is false, block the attempt and ask for a current routing number from the customer.

Timeouts and retries: treat the lookup as idempotent and safe to retry after transient failures. Add circuit breaker logic so your payments pipeline does not stall on external network events; fall back to a short-lived cache when the latest result is still recent and you cannot reach the API.

Caching and data freshness

Reference data does not change hourly, but it can change. Practical guidance:

• Cache successful routing validations for a short TTL (for example, 24 hours) keyed by routing number and payment type.
• Respect lastUpdated in responses for your observability; if you see a change, refresh your cache proactively.
• On critical steps (final ACH submission), re-check if your cached record is older than your risk policy allows.

For auditability, log the status, bank name, and lastUpdated, along with the API response timestamp in UTC. This helps reconcile discrepancies if a routing entry changes between initiation and settlement.

Security and data handling

Never store full card numbers. For card flows, a BIN is only the first digits of a PAN and is sufficient for issuer lookups. Store no more than what you need for reconciliation and compliance obligations.

For bank accounts, treat routing and account numbers as sensitive. Encrypt at rest, rotate access, and restrict who can read the data. BankDataStack responses include institutional metadata (name, address, phone) that are not PII; prefer storing these rather than additional information from users when possible.

Where routing fits alongside SWIFT, IBAN, and BIN

You’ll often juggle multiple identifiers across rails. Here’s a quick comparison using well-known examples. Note that the USA does not use IBAN for domestic payments.

For domestic U.S. ACH, validate the routing number as shown above. For cross-border or card-related checks, consult the corresponding BankDataStack endpoints in the Documentation.

End-to-end example: using the response in a payment flow

Imagine an onboarding form where a business enters their U.S. bank details. As soon as the user enters nine digits for the routing field, your backend:

1. Calls the routing/validate endpoint with routing_number=114000093 and payment_type=ach.
2. If status is success and active is true, it displays “Frost Bank – Main Office, San Antonio, TX” beneath the field.
3. Stores routingNumber, name, and addressFull with the customer profile; optionally logs phone for operator callbacks.
4. Before initiating the first ACH debit/credit, it revalidates if the cached record is older than your TTL. If unchanged, it proceeds to file creation.

This reduces keying errors, avoids avoidable ACH returns, and speeds up manual reviews because operators see canonical bank details inline.

Access, pricing, and next steps

You can start integrating with a 7-day trial. The Starter plan is $49.99/month. Create your key and start validating routing numbers immediately:

• Register for an API key and run the examples above.
• Explore additional endpoints and request/response fields in the Documentation.

FAQ

Does 114000093 work for ACH?
Yes. As shown in the sample response, paymentType is “ach” and active is true. Validate immediately before you submit a payment if your cache is stale.

How should I handle “not found” for a routing number?
Treat it as un-routable for the requested rail. Prompt the user to re-check the number or supply documentation, and block the payment until a valid, active routing number is provided.

Can I validate for other rails (e.g., wire)?
Include the payment_type parameter appropriate to your flow (e.g., “ach”). For other rails, consult the API docs to confirm support and required parameters before use.

What cache TTL should I use?
A pragmatic default is 24 hours for successful validations. Revalidate sooner before high-value transfers or if your risk policy requires fresher data.

What about IBANs in the USA?
The USA does not use IBAN for domestic payments. For U.S. ACH and checks, validate the 9-digit ABA routing number. Use SWIFT/IBAN for cross-border flows where applicable.

If you’re ready to validate routing number 114000093 and ship this check into your ACH flow, get your API key and start testing in minutes: Register.