ABA Routing Number 065000090

You’ve received an ABA routing number from a customer—065000090—and you need to confirm it’s valid, identify the bank, and decide whether to accept an ACH transfer before you schedule or post the payment. By the end of this guide, you’ll be able to validate ABA 065000090 via the BankDataStack Routing Validation API, parse the response for ACH decisioning, and integrate the check into onboarding and payment flows.

What you’ll validate about ABA 065000090

ABA routing numbers are 9-digit identifiers used by U.S. banks to route electronic transfers and checks. For 065000090, you’ll want to confirm all of the following before initiating an ACH:

• Format and checksum: the 9-digit structure and mod-10 checksum are consistent.
• Bank identity: the legal name and contact details for the institution.
• Location: city, state, and ZIP to align with customer-provided details.
• Payment modality: that you’re validating in the context of ACH (as opposed to another rail).
• Operational state: whether the routing entry is currently active.

BankDataStack’s routing validation endpoint wraps those checks and returns normalized JSON you can use at onboarding time (to prevent bad payee setup) and before payment execution (to stop returns).

One-line routing validation for 065000090

Use the Routing Validation endpoint with a POST request. Include your API key and specify the routing number and payment context.

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

The response includes the institution name, address, and operational flags you’ll use to validate ACH details. See the official sample below.

Official response for ABA 065000090

{
    "status": "success",
    "data": {
        "routingNumber": "065000090",
        "paymentType": "ach",
        "name": "Capital One, National Association",
        "addressFull": "Richmond, VA",
        "street": "P.O. BOX 85139",
        "city": "Richmond",
        "state": "VA",
        "zip": "23238",
        "type": "Main Office",
        "phone": "866-561-2580",
        "active": true,
        "lastUpdated": "2026-11-15",
        "address": "P.O. BOX 85139"
    }
}

How to use these fields:

• data.routingNumber: Confirms you validated the exact 9-digit value you received.
• data.paymentType: Context of validation (ACH in this example). Keep this consistent with your payment rail.
• data.name: Legal institution name to display and to reconcile against customer-entered bank name.
• data.city, data.state, data.zip, data.address: Cross-check against customer-provided branch or mailing info to detect typos or mismatches.
• data.type: Indicates the entry type (e.g., Main Office) which can explain why no branch street address is present.
• data.phone: Bank contact line—useful for manual resolution workflows.
• data.active: Gate ACH initiation; if false, block and prompt the user to correct the routing number.
• data.lastUpdated: Timestamp for your caching policy and audit trail.

Integrate validation into onboarding and pre-payment checks

Customer onboarding

When a user adds a U.S. bank account for ACH payouts or debits, call the validation API as they submit the routing number. If data.active is true and the institution name and location match the user’s bank selection, you can proceed to collect the account number and any additional KYC data.

Before executing an ACH

Just-in-time validation reduces ACH returns due to misrouted entries. If data.active is false or the name/location is inconsistent with the payer or payee, prompt the operator or customer to recheck their details. This can be automated with a rules engine keyed off data.active and string-similarity between data.name and a user-supplied bank name.

JavaScript example: validating 065000090 and gating ACH initiation

async function validateRouting(routingNumber) {
const response = 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 (!response.ok) {
throw new Error(`HTTP ${response.status}`);
}

const result = await response.json();

// Basic gating logic for ACH
if (result.status !== "success" || !result.data) {
return { ok: false, reason: "not_found_or_invalid" };
}

const d = result.data;
if (!d.active) {
return { ok: false, reason: "inactive_routing" };
}

// Optionally compare a user-supplied bank name:
// naive match example (adjust for your locale/casing rules)
// const userBankName = "Capital One";
// if (!d.name.toLowerCase().includes(userBankName.toLowerCase())) { ... }

return {
ok: true,
bank: {
routingNumber: d.routingNumber,
name: d.name,
city: d.city,
state: d.state,
zip: d.zip,
phone: d.phone,
lastUpdated: d.lastUpdated
}
};
}

// Usage:
validateRouting("065000090").then(console.log).catch(console.error);

This code checks for a successful response, verifies activity, and returns a concise object you can store with the payee record. Keep personally identifiable information out of logs; store only what you need for reconciliation and support.

Routing numbers: format and checksum at a glance

ABA routing numbers are 9 digits. A weighted checksum across the first eight digits yields the ninth digit. This is useful for early client-side validation to catch obvious typos before hitting the API. However, format alone cannot confirm the institution or the routing entry’s operational status—use the API for authoritative data like data.active and bank identity.

Handling “not found” and error scenarios

• Not found: If the routing number isn’t recognized in the referenced registry for your payment context, treat the response as a non-success and block the payment or prompt for correction.
• Inactive: If you receive data.active as false, do not initiate an ACH. Ask the user for a current routing number.
• Mismatched bank details: If the legal name or location differ materially from user input, require confirmation or additional verification.
• Input hygiene: Strip spaces and non-digits from the routing number before submitting. Require exactly 9 digits after normalization.

Caching and data freshness

Routing reference data changes infrequently, but it does change. Use the data.lastUpdated field to inform your caching. A practical approach is to cache successful validations for a short time window (for example, 24–72 hours) and re-validate if lastUpdated suggests newer data may be available or if you detect a user correction.

Do not cache error responses for long periods; allow customers to correct typos on a subsequent attempt. Always log the routing number and minimal response metadata for audit purposes, and avoid storing unnecessary PII.

Where routing validation fits among other identifiers

Developers working across geographies encounter multiple identifiers. The United States uses ABA routing numbers; it does not use IBAN. SWIFT/BIC codes identify banks globally for cross-border wire transfers, and BINs identify card issuers. Use the appropriate validator per rail:

Never store full card numbers in your systems—retain only what you need (e.g., BIN, last4, and a token from your PCI-compliant processor). BIN validation is available via the same BankDataStack base URL, but for routing numbers like 065000090 you should use the routing/validate endpoint shown above.

Putting it all together for ABA 065000090

When a customer provides routing number 065000090 for an ACH payout or debit, validate it with a one-line POST. If status is success and data.active is true, you have a match for Capital One, National Association in Richmond, VA. You can present the bank name back to the customer for confirmation and proceed to micro-deposit verification, instant account verification, or the ACH itself depending on your risk policy.

If you’re building a back-office tool, display the bank name, city/state, and phone for operations teams to resolve mismatches quickly. If you’re building a customer-facing flow, surface only what’s necessary, e.g., “Bank verified: Capital One (Richmond, VA).”

Next steps and references

To integrate routing validation for 065000090 and any other U.S. routing number, start with the API reference and a trial key. Read the endpoint details in the Documentation, then request access to the Starter plan ($49.99/mo) with a 7-day trial.

Get your API key and begin testing in minutes: Register.

FAQ

What does it mean if the routing number validates but the bank name doesn’t match what the user typed?
Treat it as a potential mismatch. Ask the user to confirm the institution or re-enter details. Minor variations (e.g., “Capital One” vs. “Capital One, National Association”) are common, but substantial differences should block payment until resolved.

Can I validate for other payment types with the same endpoint?
Yes, the request includes a payment_type field that scopes the validation. This example uses "ach". Keep the payment_type aligned with your intended rail when you call the endpoint.

How should I cache routing validations?
Cache successful validations for a short TTL to reduce latency and API calls, and re-validate periodically or on user edits. Use data.lastUpdated to drive refresh logic and keep an audit trail of lookups tied to your payment attempts.

Does the USA use IBAN for domestic transfers?
No. The USA does not use IBAN. Use ABA routing numbers for domestic ACH and checks, and SWIFT/BIC for cross-border wires.

Should I store full card numbers if I also validate BINs?
No. Do not store full primary account numbers. Store only what is required for your use case (e.g., BIN and last4) and rely on a PCI-compliant processor for card storage and tokenization.