Citibank - Routing 026009593 Bank Lookup

You have a US payment to send and the remittance advice says “Citibank – routing 026009593.” Before funds move, you need to confirm the routing number belongs to the bank you expect and that it supports the payment rail you plan to use (ACH or wire). By the end of this guide, you’ll validate routing number 026009593 via the BankDataStack Routing Validation API, understand what the response means in a payment flow, and know how to handle mismatches, caching, and edge cases cleanly in production.

What you’ll validate about routing 026009593

Routing numbers (ABA numbers) identify a US financial institution and often the specific office that handles a given payment type. In an onboarding or payout flow, you should confirm two things for 026009593:

• The bank name and location the number resolves to.
• Whether it supports the payment rail you intend (ACH or wire) so you can block unsupported flows early.

With BankDataStack, you’ll make a single POST to the routing validation endpoint and get normalized metadata you can show to a user, log for fraud review, or use to route funds correctly. See the Documentation for an overview of the REST shape.

Validate 026009593 with the Routing API

The following call validates the specific routing number in the title. Copy and run it with your own API key. Note that the USA does not use IBAN; for US domestic, you’ll rely on routing numbers and (optionally) account numbers captured from the counterparty.

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

Sample response (copied exactly from the live API):

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

Field usage in your flow:

• name: Display back to the user (“We found Bank Of America N.a.”). If the user entered “Citibank,” prompt them to recheck—this mismatch is a useful fraud/compliance flag.
• paymentType: Echo of your request context (ach here). Use it to enforce that rail-specific validations are applied.
• active: Gate payments; if false, halt and surface a corrective action to the user.
• type and address/location fields: Log for audit, show in UI confirmations, or apply region/business rules.
• lastUpdated: Cache invalidation hint; refresh your cache if older than your SLA (e.g., 24–72 hours).

A practical read of the mismatch: “Citibank” label vs. API result

This post focuses on the title’s scenario: the payer expects “Citibank” but the validated routing number 026009593 resolves to “Bank Of America N.a.” When your validation step returns a different institution than the payer expects:

• Block the payment and ask the user to confirm the bank name and routing number. Mismatches frequently come from reused templates or outdated instructions.
• Offer a quick re-entry path and revalidate in real time using the same API call.
• Log the discrepancy for fraud review if the counterparty pressures you to proceed without a match.

One more example call in code

This JavaScript example shows how to call the same endpoint and read the fields you’ll need to enable or block the payment.

async function validateRouting(routingNumber, paymentType = "ach") {
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: paymentType })
});

if (!res.ok) {
throw new Error(`Network or auth error: ${res.status}`);
}

const payload = await res.json();
if (payload.status !== "success" || !payload.data) {
throw new Error("Unexpected response shape");
}

const d = payload.data;
return {
isActive: Boolean(d.active),
bankName: d.name,
city: d.city,
state: d.state,
officeType: d.type,
paymentType: d.paymentType,
lastUpdated: d.lastUpdated
};
}

// Example usage in a checkout or payout flow
validateRouting("026009593", "ach")
.then(info => {
// 1) Bank name check
if (info.bankName !== "Citibank") {
console.warn("Bank mismatch:", info.bankName);
// prompt user to confirm/re-enter details; block transfer until matched
}
// 2) Active and rail support gating
if (!info.isActive) {
throw new Error("Routing is not active for this payment type");
}
// Proceed to next step: collect account number, run micro-deposits or prenote, etc.
})
.catch(err => {
console.error("Validation failed:", err.message);
});

How this fits into a payment or onboarding flow

1) Merchant onboarding or payee capture

• Collect bank name (free text), routing number, account number, and intended payment rail (ACH or wire).
• Call the routing validation endpoint with the routing number and payment_type.
• If the bank name the user typed does not match the API’s bank name, ask them to confirm or re-enter before saving.
• For ACH onboarding, optionally follow with micro-deposits. BankDataStack does not move funds; it validates the institution details.

2) Pre-transfer verification

• When assembling a payout batch, re-validate cached routing numbers that are older than your threshold window.
• Block any record where active is false or where the payment rail is unsupported for the routing range.
• Surface bank name and city in the operator console for quick visual verification.

Identifier formats, checksums, and when “not found” is expected

Routing numbers: 9 digits. The rightmost digit is a Mod 10 check digit computed via a weighted sum. BankDataStack rejects malformed length or checksum upfront and returns a validation failure before any lookup. A “not found” or inactive response can occur when:

• The number is retired, branch-merged, or only supports certain rails (ACH vs wire) and you queried the wrong rail.
• You have a data-entry error (transposed digits are common).

IBAN: The USA does not use IBAN. International counterparties may send you IBANs; validate them with the IBAN endpoint and then route via SWIFT for cross-border. The official sample IBAN you can test with elsewhere in your integration work is GB82WEST12345698765432.

SWIFT/BIC: 8 or 11 characters, alphanumeric. Used for cross-border. The official sample SWIFT in your test matrix is CHASUS33.

Card BIN: The first digits of a card number that identify the issuer and product. Never store or log full PANs. The official sample BIN for testing validations is 424242 (use only BIN-level data; do not capture entire card numbers in logs or analytics).

Use the four official fixtures in your test matrix

When building automated tests, include at least these API-known fixtures so you can confirm integrations without live customer data:

• Routing number: 021000021 (use the routing validation endpoint).
• IBAN: GB82WEST12345698765432 (use the IBAN validation endpoint; remember, not a US instrument).
• BIN: 424242 (use the BIN validation endpoint; only submit the BIN, never the full PAN).
• SWIFT: CHASUS33 (use the SWIFT validation endpoint for cross-border lookups).

All validation endpoints use POST https://www.bankdatastack.com/api/v1/{routing|bin|iban|swift}/validate with the X-API-Key header. See details in the Documentation.

Caching strategy and SLAs

Bank reference data changes infrequently, but it does change: mergers, rail support updates, contact info, or office consolidations. A practical approach:

• Cache positive results keyed by routing number and payment_type.
• Honor lastUpdated in the payload; schedule a background refresh if your cached copy is older than 24–72 hours.
• Never hardcode bank names based on user input; always prefer the API as the source of truth before funds move.

Security and privacy notes for financial identifiers

• Routing numbers are not sensitive by themselves, but treat all payment instructions as PII-adjacent. Apply least-privilege access to logs and dashboards.
• For cards, store only the BIN (first digits) plus a tokenized or vaulted reference from your processor. Never log full PANs in application logs, metrics, or traces.
• Mask account numbers in UI confirmations except for the last four digits.

How pricing and access work

BankDataStack offers a Starter plan at $49.99/month with a 7-day trial so you can wire up validation quickly in dev and staging. To proceed, get your API key at Register and drop it into the X-API-Key header shown above.

Comparing routing, SWIFT, IBAN, and BIN at a glance

Error handling and “not found” semantics

• HTTP errors (4xx/5xx): Treat as transient or configuration issues (e.g., missing/invalid API key). Do not confuse with “not found.”
• Application-level misses: If the payload indicates the number is not found or inactive for a rail, block or reroute the flow and prompt the user to confirm details.
• Data entry errors: Prompt re-entry and re-validate. Add client-side formatting where possible (numeric-only, 9 digits for routing).

End-to-end checklist for “Citibank – 026009593” scenarios

• Receive inputs: bank name (“Citibank”), routing number (026009593), rail (ACH), account number (masked).
• Call routing/validate with payment_type=ach.
• Compare API bank name with user-entered bank name. If mismatch (e.g., result shows “Bank Of America N.a.”), pause and prompt correction.
• Confirm active is true; if false, block and ask for updated instructions.
• Cache result with lastUpdated awareness; recheck before payout if cache is stale.
• Proceed to downstream funding steps only after these checks pass.

FAQ

Does the USA use IBAN for domestic payments?
No. US domestic payments use routing numbers (ACH and wire). You can still validate non-US counterparties’ IBANs using the IBAN endpoint, but you will not use IBAN for US domestic transfers.

The user insists it’s Citibank, but the API shows a different bank. What should I do?
Treat this as a blocking mismatch. Ask the user to re-verify the routing number or provide alternative instructions. Do not route funds until the bank name and routing number align.

Can I validate whether a routing number supports ACH vs wire?
Yes. Include payment_type in the request. Use the response to gate the rail you intend to use and prevent unsupported attempts.

How often should I refresh cached reference data?
Use lastUpdated as a hint. Many teams refresh on a 24–72 hour cadence and re-validate immediately before releasing funds if the cache is stale or the payment is high value.

What card data can I store when using BIN lookups?
Store only the BIN and non-sensitive metadata. Never store or log full PANs. Keep logs and analytics free of full card numbers.

Ready to wire up routing validation for 026009593 and your broader payment flows? Get an API key and start building with the 7-day trial on the Starter plan at Register, and consult the Documentation for endpoint specifics.