ABA Routing Number 026009593

You need to validate the ABA routing number 026009593 before sending or receiving an ACH payment. By the end of this guide, you’ll be able to programmatically verify that routing number with BankDataStack’s routing validation endpoint, interpret the response, and wire the result into your onboarding or payment initiation flow with confidence.

What you get from validating ABA 026009593

ABA routing numbers identify a US financial institution for domestic payments. For ACH and check processing, confirming the bank details behind the number avoids misdirected funds, returns, and delays. Using BankDataStack, you’ll validate 026009593 and retrieve the bank name, address, servicing status, and other attributes you can display to users and log for compliance.

• Confirm the bank’s legal name and mailing address for customer review.
• Detect inactive or deprecated routing numbers before submitting ACH files.
• Cache bank metadata to speed up subsequent validations and reduce user input errors.

Endpoint and example for 026009593

BankDataStack exposes a single POST endpoint for routing validation. You provide the routing_number and the intended payment_type (for example, ach). Below is a copy-pasteable cURL for the specific routing number in this article.

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"}'

The API responds with structured JSON that includes the routing number, payment rail, the institution’s name and address, contact phone, servicing status, and a last-updated date to guide your caching strategy.

Official JSON response and field usage

The following example shows a successful validation for 026009593. Use these fields to drive user confirmation, internal checks, and decisioning in your workflow.

{
    "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"
    }
}

How to use these fields:

• data.routingNumber and data.paymentType: Echo back to the customer for confirmation and tie the response to the specific rail you plan to use (ACH vs. other domestic methods).
• data.name: Display the institution’s name so the submitter can confirm it matches their expectations before you queue the payment.
• data.city, data.state, data.zip, data.street/address/addressFull: Show or log location details for audit and manual review when needed.
• data.active: Block submissions when false to reduce returns and back-office exceptions.
• data.type: Differentiate Main Office vs. branch or processing centers when building your internal reference UI.
• data.phone: Provide a quick escalation path for operations if a manual verification is required.
• data.lastUpdated: Drive TTLs in your cache and schedule periodic refreshes to keep records accurate.

JavaScript example: validating 026009593 in your service

This sample shows how to call the same endpoint from a Node.js service, read the key fields, and implement a basic guardrail before submitting an ACH payment.

import fetch from "node-fetch";

async function validateRouting(routingNumber) {
const res = await fetch("https://www.bankdatastack.com/api/v1/routing/validate", {
method: "POST",
headers: {
"X-API-Key": "YOUR_API_KEY",
"Content-Type": "application/json"
},
body: JSON.stringify({
routing_number: routingNumber,
payment_type: "ach"
})
});

if (!res.ok) {
// You may receive HTTP errors for malformed input or not found conditions.
// Check the response body per the docs for structured error details.
throw new Error(`Routing validation HTTP ${res.status}`);
}

const payload = await res.json();

// Expect payload.status === "success" for successful lookups.
if (payload.status !== "success" || !payload.data) {
throw new Error("Routing not validated");
}

const d = payload.data;

// Example: fail closed if the routing is not active.
if (d.active !== true) {
return { valid: false, reason: "Routing number is not active" };
}

// Return the fields you will display to the user or log for compliance.
return {
valid: true,
routingNumber: d.routingNumber,
bankName: d.name,
address: {
street: d.street || d.address,
city: d.city,
state: d.state,
zip: d.zip
},
phone: d.phone,
paymentType: d.paymentType,
lastUpdated: d.lastUpdated
};
}

// Example usage with the specific ABA in this article:
validateRouting("026009593")
.then(result => console.log(result))
.catch(err => console.error(err));

Integrating into onboarding and payment flows

Place routing validation at the point of data capture and again before file submission:

• Onboarding: As soon as a customer enters a routing number, call the validation endpoint. Display the bank name and city/state, and ask the customer to confirm. If active is false, prompt for correction or halt onboarding until resolved.
• Pre-submission checks: Before generating a NACHA ACH file, re-validate cached routings that are older than your TTL or whose lastUpdated suggests a refresh is prudent.
• Support tooling: Expose the name, address, and phone to operations dashboards so exceptions can be resolved without leaving the console.

ABA routing format and checksum at a glance

ABA routing numbers are nine digits. A high-level checksum uses a weighted sum of digits with weights 3, 7, and 1 repeating across the first eight digits; the ninth is the check digit. If the checksum fails, the number is malformed and should be rejected before calling the API. Even when the checksum passes, the institution may be inactive or the number retired, which is why online validation is still required.

Handling “not found” and error conditions

Plan for both success and failure paths:

• Malformed input: Reject immediately client-side (length and digit checks) and server-side (checksum) before calling the API.
• Not found: Treat a “not found” or non-success status as a hard failure for payment initiation. Allow the user to re-enter details and log the attempt for audit. Consult the Documentation for the exact error schema and status codes.
• Inactive: If data.active is false, block the payment and provide a clear message. Consider a fallback workflow for manual verification by ops if business-critical.

Caching strategy for routing data

Routing metadata changes infrequently, but it does change. Use the lastUpdated field as a cue for cache management:

• Short-term cache: Cache positive validations for 24 hours to reduce latency and API calls during active onboarding sessions.
• Long-term refresh: Maintain a server-side cache and refresh entries periodically (for example, every 7–30 days) or when prompted by lastUpdated changes.
• Negative caching: Cache “not found” results briefly (for example, a few minutes) to avoid bursts from repeated invalid input while still allowing quick corrections.

Comparing routing numbers with other payment identifiers

Different identifiers are used for different rails and geographies. Keep each lookup in its lane to avoid false validations.

Security and data handling considerations

• Never store full card PANs in your application. A BIN is only the first 6–8 digits used for issuer identification; treat all card data per PCI DSS if processed.
• Limit PII: Store only routing and account numbers required for payout operations and encrypt them at rest. Use the validation response for display and verification, not as a primary data store.
• Audit trail: Log validation attempts with minimal data (routingNumber, paymentType, status) alongside who initiated the change for compliance.

Pricing, trial, and getting an API key

BankDataStack offers a Starter plan at $49.99/month with a 7-day trial so you can integrate routing validation for 026009593 and other numbers in a sandbox-to-prod path. To begin, get an API key from the Register page and review endpoint details in the Documentation.

Putting it together: a practical checklist

• Input validation: 9 digits, numeric-only, checksum passes.
• Call POST /api/v1/routing/validate with routing_number=026009593 and payment_type=ach.
• Require payload.status === "success" and data.active === true before proceeding.
• Display data.name and city/state for customer confirmation.
• Cache successful validations with a sensible TTL; refresh using lastUpdated cues.
• On error or not found, block the payment and prompt for correction or manual review.

Frequently asked questions

Does a valid checksum guarantee the routing number is usable?
No. The checksum only validates format. You still need an online lookup to confirm the bank association and whether the routing number is active.

Can I use this routing number for international transfers?
No. ABA routing numbers are for US domestic rails. For international wires, you’ll need a SWIFT/BIC (for example, CHASUS33) and the destination country’s account format. The USA does not use IBAN.

What should I do if the API returns not found or inactive?
Reject the payment setup, ask the user to re-enter details, and consider manual verification by operations if necessary. Review error shapes and edge cases in the Documentation.

How often should I refresh cached routing data?
Use a layered approach: 24-hour short-term cache during onboarding and a periodic server-side refresh (for example, 7–30 days). If lastUpdated indicates a more recent change, refresh immediately.

Is the phone number provided intended for end users?
Treat phone as an operations reference for escalations. Do not automatically surface it to customers without context or consent.

Validate ABA 026009593 now and wire this check into your ACH flow in minutes. Get your API key at the BankDataStack Register page and ship with confidence after reviewing the Documentation.