ABA Routing Number 122105278

ABA Routing Number 122105278

You have a routing number on a payment instruction—122105278—and you need to verify the bank, branch location, and ACH eligibility before you release funds. By the end of this guide, you’ll be able to validate ABA routing number 122105278 via the BankDataStack Routing Validation API, read the results you need for ACH payments, and integrate the check into your onboarding or payment flow.

What ABA Routing Number 122105278 Represents

ABA routing numbers identify U.S. financial institutions for payments like ACH and wires. The number 122105278 is a nine-digit identifier used to route transactions to a specific bank and branch. For payment operations, routing numbers matter because:

Illustration: ABA Routing Number 122105278
  • They are required on ACH and wire payment instructions.
  • They carry a checksum so typo errors can be detected automatically.
  • They map to a single bank and location, which helps catch mismatches between a customer’s stated bank and the actual institution.

Validating a routing number is a quick, low-friction control that prevents late-stage payment failures and reduces manual outreach when details don’t line up.

Endpoint Overview and Authentication

Use the routing validation endpoint to verify an ABA number and the supported payment rail:

  • Method: POST
  • URL: https://www.bankdatastack.com/api/v1/routing/validate
  • Auth: X-API-Key header
  • Content-Type: application/json

If you don’t have an API key, start with the 7-day trial on the Starter plan ($49.99/mo). You can get an API key in minutes at the Register page. See request/response fields in the Documentation.

Copy-Paste cURL to Validate 122105278 for ACH

The following live sample validates routing number 122105278 for ACH payments. Copy it as-is, pasting your API key:

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

Official Sample Response and Field Guide

Here is the official JSON response for 122105278, returned by the live Routing Validation API:

{
    "status": "success",
    "data": {
        "routingNumber": "122105278",
        "paymentType": "ach",
        "name": "Wells Fargo Bank Na (arizona)",
        "addressFull": "255 2nd Ave South, Minneapolis, MN 55479",
        "street": "255 2nd Ave South",
        "city": "Minneapolis",
        "state": "MN",
        "zip": "55479",
        "type": "Main Office",
        "phone": "800-745-2426",
        "active": true,
        "lastUpdated": "2026-10-29",
        "address": "255 2ND AVE SOUTH"
    }
}

How to use these fields:

  • data.routingNumber: Echo of the input so you can log and correlate the validation with the payment record.
  • data.paymentType: Confirms the rail (ach) you requested validation for, useful when flows support multiple rails.
  • data.name: Bank name you can display back to the user and compare with what they typed to catch mismatches.
  • data.city, data.state, data.addressFull/ street/ zip: Location and mailing details for compliance screens, support tickets, or auto-filling bank info in back-office tools.
  • data.type: Branch or office classification (e.g., Main Office) to understand routing coverage.
  • data.phone: Public bank phone number for manual verification steps.
  • data.active: Whether the routing number is currently active for the rail; block or manual-review if false.
  • data.lastUpdated: Date reference to support your caching and audit evidence.

Integrate the Check in Your Payment or Onboarding Flow

Most teams validate the routing number during customer onboarding or just-in-time before money movement:

  • At onboarding: When a user enters bank account details, call the validation endpoint immediately. If it returns success, prefill the bank name to reassure the user. If the bank name doesn’t match what they typed, prompt for a quick confirmation.
  • Before ACH submission: Re-validate if your cached copy is stale, confirming active is true for payment_type=ach. If active is false or lookup fails, stop the payment and create a queue item for ops review.

Operational outcomes to implement:

  • Hard fail on checksum errors (invalid nine-digit format will fail the checksum; see notes below).
  • Soft fail or step-up verification if data.name is different from the user-selected bank name.
  • Block or hold if data.active is false.
  • Log data.lastUpdated alongside your local cache timestamp for audits.

JavaScript Example: Server-side Validation

Here is a Node.js example that calls the same endpoint and reads the fields you’ll use for decisioning:

import fetch from "node-fetch";

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

// Expecting a JSON with { status, data }
const json = await resp.json();

if (json.status !== "success" || !json.data) {
// Treat as not-found or invalid for your flow
return { ok: false, reason: "lookup_failed", raw: json };
}

const d = json.data;
return {
ok: true,
routingNumber: d.routingNumber,
bankName: d.name,
city: d.city,
state: d.state,
active: d.active,
addressFull: d.addressFull,
phone: d.phone,
paymentType: d.paymentType,
lastUpdated: d.lastUpdated
};
}

// Example usage
validateRouting("122105278").then(result => {
if (!result.ok) {
console.error("Routing validation failed:", result.reason);
// Place the payment in manual review
return;
}
if (!result.active) {
console.error("Routing is not active for ACH:", result.routingNumber);
// Block the payment
return;
}

console.log(`Bank: ${result.bankName} (${result.city}, ${result.state})`);
// Proceed to link the account and submit ACH
}).catch(err => {
console.error("Request error:", err);
});

ABA Format and Checksum: What Your Code Should Enforce

ABA routing numbers are nine digits. The ninth digit is a checksum over the first eight. A common pattern in banking stacks is to run a client-side or service-tier checksum check so obvious typos never reach downstream processors.

At a high level:

  • Length: 9 digits, numeric only.
  • Checksum: Calculated over digits 1–8; the sum, after applying the standard ABA weighting, makes the total divisible by 10 when including digit 9.
  • Use: ACH, wires, and check processing. When you validate with payment_type set to ach, ensure the routing supports that rail.

The routing validation endpoint handles this for you, but local pre-checks provide better user feedback and reduce unnecessary API calls.

Handling “Not Found” and Error Cases

Occasionally a lookup won’t return a match or won’t meet your criteria:

  • No match or invalid: Treat the response as a failure state for the entered routing number and prompt the user to re-check digits. Do not attempt to infer or autocorrect to a nearby routing number.
  • Mismatched or inactive for rail: If the number is inactive for ACH or doesn’t match the user’s stated bank, move the payment to manual review or ask the user to confirm their bank selection.
  • Network or transient error: Implement retries with backoff. If a timeout occurs, save the payment in “pending validation” and re-queue the task.

Always log the response body and your decision. In audit scenarios, it’s helpful to preserve data.status along with data.lastUpdated and the timestamp of your decision.

Caching Strategy and Data Freshness

Routing data is relatively stable but can change. A pragmatic cache strategy:

  • Cache by routing number and payment_type.
  • Set a TTL aligned to your risk posture (e.g., 7–30 days for onboarding checks). For time-sensitive outbound payments, re-validate if the cached entry is older than your TTL before authorizing release of funds.
  • Store the returned lastUpdated date with your cache entry for extra context and reporting.
  • Purge cache on error or if the bank reported by data.name materially changes from your stored value.

Use strict cache keys to avoid mixing ACH and other payment types in your logic.

Security and Data Handling Notes

BankDataStack returns bank metadata about the routing number; it does not require or return customer PII. Still, treat responses as sensitive operational data:

  • Never store full card numbers in your systems. If you also validate BINs elsewhere in your platform, retain only the BIN (first 6–8 digits as applicable), not the full PAN.
  • Restrict access to validation logs to your risk, compliance, and payments engineering teams.
  • Use HTTPS only and rotate your API key on role changes or suspicion of compromise.

How This Fits with Other Identifiers

If your product handles multiple regions or rails, align your validation logic with the identifier type:

  • ABA routing (U.S.): Use the routing validation endpoint shown here. The USA does not use IBAN.
  • SWIFT/BIC (cross-border): Validate the BIC used for international transfers through the SWIFT endpoint when applicable to your product scope.
  • IBAN (non-U.S. domestic): Validate structure and bank mapping for EEA and other IBAN-using countries via the IBAN endpoint; not applicable to U.S. domestic transfers.
  • BIN (cards): Use the BIN endpoint for card issuer identification during card onboarding and fraud screening.

The flows are similar—validate first, then reconcile the returned institution name and country against user input to catch mismatches. For the 122105278 use case, stay within the routing validation flow for ACH.

Putting It Together: A Minimal ACH Validation Flow

1) Collect and pre-validate

  • Ensure routing number is 9 digits; run a local checksum if implemented.
  • Collect the user’s stated bank name for later comparison.

2) Call routing validation

  • POST to /api/v1/routing/validate with routing_number=122105278 and payment_type=ach.
  • Require status=success; otherwise treat as not found or invalid.

3) Decisioning

  • If active is true and name matches within your tolerance, proceed.
  • If name mismatch, prompt user to confirm the bank or route to manual review.
  • If active is false, block and notify the user to supply a different account.

4) Persistence and audit

  • Store routingNumber, name, city, state, active, lastUpdated, and timestamp of your check with the payment record.
  • Set a refresh schedule based on your TTL policy.

Testing Notes and Sandbox Strategy

To test your integration against known-good requests, use the same request that appears in the official sample for 122105278 and confirm you receive the documented fields. For negative-path tests, try invalid lengths or non-numeric input on your local checksum pre-check to simulate rejection before the API call. This approach lets you test user messaging and UI validation flows without generating noise in your API logs.

Operational Playbook for Support and Risk

Support and risk teams benefit from a simple check sheet for routing anomalies:

  • User reports “payment failed”: Verify your logs show status=success for the routing lookup and active=true at time of initiation.
  • Bank mismatch dispute: Compare the name and city/state from the API with the counterparty’s claim. If they differ, request a bank letter or voided check image from the customer as a second factor (masked as appropriate).
  • Periodic audits: Export records with routingNumber, name, active, and lastUpdated to validate your caching policy and ensure stale entries are refreshed.

Common Pitfalls to Avoid

  • Skipping checksum: This allows obvious typos to reach operations, increasing NOC returns and reconciliation time.
  • Not specifying payment_type: Rails can differ; explicitly validate for ach when sending ACH.
  • Over-caching: Routing data is stable but not immutable; respect TTL and re-validate before high-value disbursements.
  • Storing unnecessary PII: Keep only the fields needed for decisions and audits; never store full card numbers, and avoid duplicating sensitive logs.

FAQ

Does routing number 122105278 support ACH?
Yes. The sample response shows paymentType=ach and active=true, indicating the number is valid and active for ACH processing.

What should I do if the API returns a non-success status?
Treat it as a validation failure for that routing number and prompt the user to re-check details, or queue the item for manual review. Do not try to guess a nearby routing number.

Should I cache routing validation results?
Yes—cache by routing number and payment_type with a defined TTL. Before releasing funds, re-validate if your cached copy is stale. Store lastUpdated with your cache for audit trails.

Can I use IBAN for U.S. bank accounts?
No. The USA does not use IBAN. Use ABA routing numbers for domestic U.S. transfers and SWIFT/BIC for cross-border, as applicable.

What fields are safe and useful to persist?
Persist routingNumber, name, city/state, active, lastUpdated, and your validation timestamp. Avoid storing any unneeded personal data and never store full card numbers.

Ready to implement routing validation for 122105278 and beyond? Get your API key on the Register page, then review the request and response details in the Documentation to ship your integration.

Keywords
ABA routing number validation API development for banking verify ABA routing number BankDataStack API guide ACH eligibility check

Ready to get started?

Get your API key and start validating bank data in minutes.

Get API Key

Related posts