US Bank - Routing 091000022 Bank Lookup

Your ops team needs to confirm that routing number 091000022 actually belongs to U.S. Bank before releasing an ACH payment or wiring onboarding micro-deposits. By the end of this guide, you’ll know how to validate 091000022 via the BankDataStack Finance API, parse the bank details you need in code, handle “not found” cases safely, and decide what to cache in your payment flows.

What 091000022 represents and when to validate it

Routing numbers (ABA RTNs) identify a U.S. depository institution for ACH and wire transfers. 091000022 is assigned to US Bank Na. If you’re collecting checking details in an onboarding form or processing payouts, validating the routing number lets you surface bank name and location, block typos early, and route ACH files correctly.

With BankDataStack, you send the routing number and a payment type (e.g., ach) and receive the official institution metadata as JSON. You can plug this into your KYC/KYB or payout workflow with a single POST.

Quick look: one API call to validate 091000022

Use the Routing Validation endpoint. Keep your API key in the X-API-Key header. The example below checks 091000022 for 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":"091000022","payment_type":"ach"}'

Sample response:

{
    "status": "success",
    "data": {
        "routingNumber": "091000022",
        "paymentType": "ach",
        "name": "Us Bank Na",
        "addressFull": "St. Paul, MN",
        "street": "EP-MN-WN1A",
        "city": "St. Paul",
        "state": "MN",
        "zip": "55107-1419",
        "type": "Main Office",
        "phone": "800-937-6310",
        "active": true,
        "lastUpdated": "2026-09-23",
        "address": "EP-MN-WN1A"
    }
}

What you’ll use immediately:

• name: Display “Us Bank Na” back to the user for confirmation and audit trails.
• city/state/zip: Optional in your UI; useful to disambiguate branches and for back-office checks.
• active: Block payouts if inactive.
• paymentType: Echo of your request; log it to prove you validated for the right rail (ach vs. wires if you later support them).
• lastUpdated: A reference timestamp for cache freshness controls or audit logging.

Implement it in Python

The snippet below posts the routing number, validates success, and extracts the bank’s name and location for your payment form or payout engine.

import json
import requests

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

def validate_routing_ach(routing_number: str) -> dict:
payload = {
"routing_number": routing_number,
"payment_type": "ach"
}
headers = {
"X-API-Key": API_KEY,
"Content-Type": "application/json"
}
r = requests.post(API_URL, headers=headers, data=json.dumps(payload), timeout=10)
r.raise_for_status()
body = r.json()

# Basic contract check using fields shown in the sample
if body.get("status") != "success" or not body.get("data"):
raise ValueError(f"Routing number not validated: {body}")

data = body["data"]
return {
"routingNumber": data.get("routingNumber"),
"bankName": data.get("name"),
"city": data.get("city"),
"state": data.get("state"),
"zip": data.get("zip"),
"active": data.get("active"),
"lastUpdated": data.get("lastUpdated")
}

if __name__ == "__main__":
result = validate_routing_ach("091000022")
if not result["active"]:
raise SystemExit("Bank is inactive for ACH.")
print(f"Validated {result['routingNumber']} - {result['bankName']} ({result['city']}, {result['state']})")

Where this logic plugs in:

• Onboarding: As the user tabs out of the routing input, call validate. Show “Us Bank Na — St. Paul, MN” beneath the field and store the response fields you need.
• Payments: Before adding entries to your ACH batch, re-check active for cached items nearing expiry to avoid rejects.
• Support tooling: Add a lookup panel that hits the API and displays addressFull and phone for agent reference.

How routing numbers and checksums work (quick)

ABA routing numbers are nine digits. A simple checksum uses weights 3, 7, and 1 across the first eight digits; the total plus the ninth digit (the check digit) should yield a sum that is a multiple of 10. While you don’t need to implement this yourself when you use BankDataStack, understanding it helps when you short-circuit obvious typos on the client side before calling the API.

Even if a number passes the checksum, it might be inactive or mismatched for the payment rail you plan to use (ACH vs. other rails). That’s why you should still validate against authoritative bank metadata at submission time.

Operational behaviors: success, not found, and retries

In happy paths, you’ll receive status: "success" and a populated data object with fields like name, city, and active. If the number is invalid, inactive, or not present, expect the status to not indicate success or the data object to be missing. In either case, don’t guess; block the transfer, display a clear validation error, and prompt for correction.

Network timeouts and transient 5xx responses should be retried with exponential backoff. For interactive UIs, couple client-side format checks with a single server-side validation call; for backend batch processing, treat validation failures as hard errors that require data review.

Caching and freshness

Routing metadata is relatively stable but can change (mergers, branch status updates). A common pattern is to cache successful lookups for 7–30 days and to record the lastUpdated field from the response. When your cache entry predates lastUpdated or exceeds your TTL, refresh from the API before payouts run. For payment-critical steps (e.g., first-time payout to a new counterparty), validate live even if you have a cached entry.

To minimize latency in your checkout or onboarding UI, you can perform background refreshes for cached routings after form submission, and alert users only if the refresh detects a mismatch.

Where 091000022 fits in your ACH workflow

Collect the routing number and account number from the user. Before you schedule ACH debits or credits, call the validation endpoint with the routing number and payment_type set to ach. Use the returned bank name and location to confirm the bank the user expects (e.g., “Us Bank Na — St. Paul, MN”). Store routingNumber, bank name, and a timestamp proving you validated pre-payment.

If you also implement micro-deposits, do the same validation when creating the ledger entries. Keep a record of the API response status and lastUpdated with your micro-deposit attempt to make reconciliation easier when a return happens.

Related identifiers and how they compare

BankDataStack validates several identifier types. If your product also touches international payouts or card onboarding, it helps to understand their shapes and what you should or should not store. The United States does not use IBAN, but you may need to validate IBANs for foreign beneficiaries.

The four canonical fixtures (for testing your integration)

To smoke-test your implementation without guessing values, BankDataStack provides four well-known identifiers across the Finance endpoints:

• Routing: 021000021 (use /api/v1/routing/validate)
• IBAN: GB82WEST12345698765432 (use /api/v1/iban/validate). Note: the USA does not use IBAN, but your app may need to support it for foreign beneficiaries.
• BIN: 424242 (use /api/v1/bin/validate). A BIN is the first digits only; never store the full card number.
• SWIFT: CHASUS33 (use /api/v1/swift/validate)

These fixtures are intended for end-to-end checks in non-production or safe testing scenarios. For this article’s core use case—validating US Bank’s 091000022—you’ve already seen the exact routing validation request and JSON.

Security and compliance notes for payments teams

• Scope-by-rail validation: Always validate against the rail you will use. For example, validate routing numbers with payment_type = ach when preparing ACH files.
• Card BIN hygiene: If you also validate BINs, persist only the BIN and derived metadata (issuer, scheme, country). Never persist full PANs in your application database.
• Data minimization: Store only what you need from the response (e.g., routingNumber, bank name, active, lastUpdated). Avoid storing the entire payload if you don’t need it.
• Auditing: Record when and how you validated: timestamp, identifier, payment type, and a reference to the response status. This helps in dispute investigations.

Integrating 091000022 validation into a payment and onboarding flow

At capture time (front end)

• Client format check: routing numbers should be 9 digits. Optionally run a lightweight checksum before hitting your server.
• Server validation: POST the routing number to /api/v1/routing/validate with payment_type = ach. If status is success and active is true, persist the identifier and bank metadata.
• User feedback: Show the bank name and city/state inline so the user can self-correct if they picked the wrong bank.

Before you send money

• Cache check: If the cached record is older than your TTL or predates lastUpdated, refresh.
• Re-validate risky payouts: For first-time payouts or high-value transfers, re-validate even if you have a recent cache entry.
• Logging: Attach the routing validation evidence (routingNumber, name, lastUpdated) to the payment record for auditing.

Pricing and how to get started

You can start with a 7-day trial and a Starter plan at $49.99/mo when you’re ready to ship. Get your API key and try your first validation in minutes.

• Register
• Documentation

Troubleshooting tips for 091000022

• Mismatch in bank name: If your UI shows a different bank name than expected, verify that you passed the correct routing number and payment_type. Re-validate to eliminate a stale cache entry.
• Inactive returned: Do not proceed with ACH if active is false. Prompt the user to confirm their details or choose a different account.
• Rate and timeout handling: Use server-side retries with exponential backoff for transient network errors. Do not retry client-side directly from the browser; route via your backend.

FAQ

Does validating 091000022 also verify the user’s account number?
No. Routing validation confirms the bank institution metadata. Account-number verification requires additional steps (e.g., micro-deposits). Use routing validation alongside your account verification process.

What should I store from the routing validation response?
Store the routingNumber, bank name (name), active flag, city/state (optional), and a timestamp (e.g., lastUpdated plus your validation time). Avoid storing fields you don’t need.

How often should I re-validate cached routing numbers?
For most merchants, 7–30 days works. Always re-validate for first-time payouts and high-risk transfers. If your cache entry predates the API’s lastUpdated field, refresh immediately.

Can I validate SWIFT codes and IBANs with the same API?
Yes. Use /api/v1/swift/validate for SWIFT/BIC and /api/v1/iban/validate for IBAN. The USA does not use IBAN, but you can validate non-US beneficiaries’ IBANs.

Do I need to run the ABA checksum myself?
No. The API will validate the routing number. Client-side checksum checks can reduce round-trips, but always validate on the server before moving funds.

Ready to validate US Bank’s 091000022 and ship your ACH flow? Create an account, grab your key, and run the curl above against your backend today: Register. For request/response details and additional Finance endpoints, see the Documentation.