Bank of America - Routing 026009593 Bank Lookup

You need to confirm whether routing number 026009593 truly belongs to Bank of America before releasing an ACH transfer or onboarding a US payee. By the end of this guide, you’ll be able to validate this exact routing number using the BankDataStack Routing Validation API, interpret the response fields you actually need in production, and fold the result into your ACH payment and vendor onboarding flows with confidence.

Why verify Bank of America routing 026009593 before an ACH?

ACH and wire returns waste engineering and operations time, delay settlement, and can trigger fraud reviews. Routing number 026009593 is widely referenced as a Bank of America routing number. With an API-backed lookup, you can confirm it resolves to Bank Of America N.A., retrieve the servicing address and phone, and check whether the record is active before releasing a credit or onboarding a counterparty entry.

The BankDataStack validation endpoint returns normalized bank metadata as JSON that you can log, display to ops, or map into your payment rail models. It also includes a lastUpdated field you can use for cache invalidation.

Validate 026009593 via API

Use the routing validation endpoint with your API key. The example below targets the specific identifier in this article (026009593) and declares the payment_type as ach.

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":"026009593","payment_type":"ach"}'

If the routing number is recognized, you’ll receive a success status and a data payload describing the bank and branch-level details. The following is a realistic response for this lookup and is the reference for the field names you should code against.

{
    "status": "success",
    "data": {
        "routingNumber": "026009593",
        "paymentType": "ach",
        "name": "Bank Of America N.a.",
        "addressFull": "Richmond, VA",
        "street": "P.O. BOX 27025",
        "city": "Richmond",
        "state": "VA",
        "zip": "23261-7025",
        "type": "Main Office",
        "phone": "800-446-0135",
        "active": true,
        "lastUpdated": "2026-10-26",
        "address": "P.O. BOX 27025"
    }
}

Key fields to consume in your workflow:

• name: Bank name resolved from the routing number. Use to display “Bank Of America N.A.” back to a user or agent for confirmation.
• active: Boolean indicating if the routing record is active. Block or escalate if false.
• type: Often “Main Office” or branch-type metadata. Helpful for ops auditing.
• address, city, state, zip, phone: Contact and location details for internal verification, manual callbacks, or printed remittance.
• lastUpdated: Use as a cache validation signal and to support audit logs with data freshness.
• routingNumber and paymentType: Echo of the request for idempotent logging and tracing.

Integrate into your ACH payment flow

Most teams call the routing validator during:

• Onboarding: When a payee enters their bank details, validate the routing before accepting the account number.
• Pre-disbursement: Before first payment or when details change, re-check the routing to catch deprecations.
• Risk and Compliance: Enrich transactions with resolved bank name and location to improve rules and manual review notes.

Recommended logic:

• If status != success, require correction or escalate to manual review.
• If active is false, block ACH initiation and prompt for a different routing number.
• Display the resolved name and city/state to the customer for an inline “Does this look right?” confirmation step.
• Cache the successful resolution keyed by routingNumber and paymentType, and refresh based on lastUpdated or a fixed TTL.

Python example: validate and consume response fields

The following snippet posts the same routing (026009593) and maps the fields you’ll typically persist or pass to downstream services. Replace YOUR_API_KEY with your key.

import requests

API_URL = "https://www.bankdatastack.com/api/v1/routing/validate"
API_KEY = "YOUR_API_KEY"

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

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

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

if data.get("status") != "success" or "data" not in data:
raise ValueError("Routing lookup failed or returned no data")

r = data["data"]

resolved = {
"routing_number": r.get("routingNumber"),
"payment_type": r.get("paymentType"),
"bank_name": r.get("name"),
"active": r.get("active"),
"branch_type": r.get("type"),
"address": {
"street": r.get("street") or r.get("address"),
"city": r.get("city"),
"state": r.get("state"),
"zip": r.get("zip"),
"address_full": r.get("addressFull")
},
"phone": r.get("phone"),
"last_updated": r.get("lastUpdated")
}

if not resolved["active"]:
# Block ACH setup or payment initiation
raise ValueError("Routing number is inactive")

# Example: show confirmation text to a user or log for ops
confirmation = f"{resolved['bank_name']} ({resolved['address']['city']}, {resolved['address']['state']})"
print("Resolved bank:", confirmation)

In production, pair this with your own account-number masking logic (never log full account numbers) and a retry policy limited to safe idempotent attempts.

ABA routing number format and checksum (high level)

US ABA routing numbers are 9 digits. The first eight digits identify the institution and region; the ninth is a check digit. A standard weighted checksum is applied using a 3-7-1 pattern across the digits; if the weighted sum modulo 10 is not zero, the number fails the checksum. This check helps you catch transposition and single-digit errors before making an API call or submitting an ACH file.

Practical tips:

• Enforce exactly 9 numeric digits in UI and backend validation.
• Run a local checksum check first; if it fails, short-circuit and prompt for correction.
• If checksum passes, still call the API to confirm ownership (name, location) and activity.

Handling not found and other edge cases

When the routing number is not recognized, you will not receive a success payload with bank data. Treat this as a validation failure and request correction from the user. Common causes:

• Typo or transposed digits (checksum may still pass in rare cases, hence API verification).
• Outdated or retired routing number (active would be false if present; not found if completely retired and purged).
• Wrong payment type: Some routing numbers differ by rail; ensure payment_type matches ach when you intend ACH.

For transient network errors or timeouts, retry with exponential backoff. Do not retry on deterministic failures like checksum errors.

Data freshness and caching

Reference data doesn’t change frequently, but it does change. Use lastUpdated from the response to power cache invalidation. A practical policy:

• Cache successful resolutions of 026009593 (and other routings you verify) for 24–72 hours keyed by routingNumber and paymentType.
• If lastUpdated indicates a newer date than your cached entry, refresh immediately.
• For onboarding forms, re-validate on first payout or after any user edit.

This reduces latency and cost while keeping your data aligned with current bank records.

Related identifiers and cross-checks

Although this article focuses on Bank of America routing 026009593 for ACH, many teams build a single validation layer that also supports SWIFT/BIC, IBAN, and card BINs for global coverage and card-on-file use cases. Below are the official fixtures you can use for smoke tests of each validator. Note: The USA does not use IBAN for domestic payments.

You can call each validator with the same pattern: POST to the appropriate /api/v1/{routing|iban|bin|swift}/validate endpoint with your API key header. See the Documentation for the exact request body schemas per identifier.

Security: what to store and what to avoid

Keep cardholder and bank data exposure minimal:

• Never store full card numbers. If you handle cards, derive and store only BIN-level attributes and a token from your PCI-compliant processor.
• Log only the routing number, resolved bank name, and the boolean active result; mask or omit sensitive fields in user-visible logs.
• Protect your API key in server-side secrets management; do not call from client-side code.
• Throttle inputs and rate-limit by user/session to mitigate brute-force attempts on routing/account combinations.

Operational guardrails for ACH with 026009593

When you receive the successful resolution for Bank Of America N.A. (Richmond, VA) with active true:

• Display the resolved bank name and state to the user for confirmation.
• Run your own account-number checksum or length rules if applicable to your business (note: the U.S. has no universal bank account checksum; validations are often per-client or per-rail).
• Record lastUpdated and your validation timestamp for audit trails tied to the customer profile.
• For recurring payments, re-check the routing on significant events (address change, failed payment, or annually).

Testing and QA with official fixtures

Beyond Bank of America’s 026009593, you can test your integration plumbing with the known-good fixtures:

• Routing: 021000021 via /api/v1/routing/validate
• IBAN: GB82WEST12345698765432 via /api/v1/iban/validate
• BIN: 424242 via /api/v1/bin/validate
• SWIFT: CHASUS33 via /api/v1/swift/validate

Fixture calls should not ship to production business logic for live payouts; use them in staging or with feature-flagged test paths to verify request signing, JSON parsing, and error handling. Keep your production checks centered on the user-supplied identifiers, like 026009593 for Bank of America ACH.

Pricing and how to start

You can begin with a 7-day trial. The Starter plan is $49.99/month and is enough to stand up a validation layer for onboarding forms and pre-disbursement checks. Create an account to get an API key and run your first validation against routing 026009593 for Bank of America.

Register for an API key, then follow the Documentation to integrate the routing validator in your ACH flow.

FAQ

Does 026009593 belong to Bank of America?
Yes. The validation response resolves routingNumber 026009593 to Bank Of America N.A. with a Richmond, VA address and an active status, suitable for ACH when paymentType is ach.

What does active true mean?
It indicates the routing record is in service. If false, block the payment and ask the user to provide an alternative routing number.

What if the API returns not found or a non-success status?
Treat as a validation failure. Prompt for correction and do not release funds. Consider adding an inline checksum validator and user confirmation step to reduce retries.

Does the United States use IBAN?
No. The USA does not use IBAN for domestic transfers. Use ABA routing numbers (such as 026009593) for ACH and wire, and SWIFT/BIC for cross-border wires when applicable.

Can I store card numbers or full PANs when using BIN validation?
No. Never store full PANs. Store only the BIN and tokenized references from your PCI-compliant processor. BINs are the first digits used to resolve issuer metadata.