Chase Bank Bank Identifier API

You need to confirm that a customer’s payment details actually point to Chase Bank before you send money or approve a card transaction. By the end of this guide, you’ll be able to validate Chase’s SWIFT/BIC, U.S. routing number (ABA), a sample BIN, and understand IBAN considerations for U.S. accounts using the BankDataStack Finance API—ready to drop into your payments, onboarding, or fraud checks.

What you can validate for Chase Bank with BankDataStack

BankDataStack provides four Finance validation endpoints under a single pattern: POST https://www.bankdatastack.com/api/v1/{routing|bin|iban|swift}/validate. Each endpoint returns a compact JSON with the issuing bank, branch, city, and country so you can gate payments, enrich dashboards, or log proof of due diligence.

• Chase SWIFT/BIC: CHASUS33 (commonly used for New York, United States)
• Chase U.S. routing number (ABA): 021000021
• Card BIN (first digits only; do not store a full PAN): 424242
• IBAN fixture: GB82WEST12345698765432 (note: U.S. banks, including Chase, do not issue IBANs for domestic U.S. accounts)

All four checks use the same authentication method via an X-API-Key header, and each returns a uniform set of fields you can rely on in a payment or onboarding flow.

Identifier formats, checksums, and what “valid” means

• SWIFT/BIC: 8 or 11 characters (institution, country, location, optional branch). Basic structural checks confirm length and character class; data validation confirms a known institution and location code. For Chase, you will commonly encounter CHASUS33.
• U.S. routing number (ABA): 9 digits with a check-digit formula. A valid result means the checksum is correct and the number maps to a known U.S. depository institution and region.
• BIN (Bank Identification Number): The first 6 to 8 digits of a card number. Use it to identify the issuing bank and card network. Never store the full PAN; store only the BIN if you must.
• IBAN: Country-specific length and checksum rules. The United States does not use IBAN; U.S. customers banking with Chase will not have a U.S. IBAN. International customers may have IBANs for accounts at non-U.S. branches or partner banks outside the U.S.

When the API says valid: true, you have a confirmed mapping to a known bank profile and location, suitable for pre-transfer validation or KYB-style checks. When valid: false or when a not-found occurs, you should block or escalate: the code may be mistyped, out of date, or not assigned.

Quick reference: SWIFT vs Routing vs IBAN vs BIN

Authentication and endpoints

All requests use POST and require X-API-Key for authentication:

• POST https://www.bankdatastack.com/api/v1/swift/validate
• POST https://www.bankdatastack.com/api/v1/routing/validate
• POST https://www.bankdatastack.com/api/v1/iban/validate
• POST https://www.bankdatastack.com/api/v1/bin/validate

Send the identifier in the JSON body. Responses return the issuing bank, branch, city, and country. For full request/response semantics, see the Documentation.

cURL: validate Chase’s SWIFT/BIC (CHASUS33)

This request validates CHASUS33 and returns the bank profile fields you can use in a wire-initiation screen or to enrich a counterparty profile. Replace YOUR_API_KEY with your key.

curl -sS -X POST "https://www.bankdatastack.com/api/v1/swift/validate" \
-H "Content-Type: application/json" \
-H "X-API-Key: YOUR_API_KEY" \
-d '{
"value": "CHASUS33"
}'

Example JSON response

Values are illustrative but reflect the documented fields. Use valid and the location fields to gate payments and display confirmations.

{
"valid": true,
"bank": "JPMorgan Chase Bank, N.A.",
"branch": "New York",
"city": "New York",
"country": "US",
"input": "CHASUS33"
}

How to use it:

• Show “JPMorgan Chase Bank, N.A., New York, US” next to the SWIFT input so the payer can confirm they’re wiring to the correct institution.
• If valid is false or the city/country do not match the expected destination, block the transfer and ask the user to correct details.
• Log input with the normalized bank fields for audit. Do not store any full card PANs when working with BINs—store only the BIN.

Python: validate Chase’s U.S. routing number (021000021)

Use this in onboarding or before an ACH/wire to confirm the routing number maps to Chase.

import json
import urllib.request

url = "https://www.bankdatastack.com/api/v1/routing/validate"
payload = json.dumps({"value": "021000021"}).encode("utf-8")
req = urllib.request.Request(url, data=payload, method="POST")
req.add_header("Content-Type", "application/json")
req.add_header("X-API-Key", "YOUR_API_KEY")

with urllib.request.urlopen(req, timeout=10) as resp:
data = json.loads(resp.read().decode("utf-8"))

# Minimal field handling
if data.get("valid"):
bank = data.get("bank")
city = data.get("city")
country = data.get("country")
print(f"Routing OK: {bank}, {city}, {country}")
else:
raise ValueError("Routing validation failed; block or escalate")

What to do with the response

• ACH setup: auto-fill bank = JPMorgan Chase Bank, N.A. on success and display the city/country for user confirmation.
• Risk rules: if valid is false for a U.S. routing, prevent submission; if city/country diverge from expected, require manual review.
• Ops tooling: show the normalized bank name and location so operators can cross-check beneficiary instructions quickly.

Validating a BIN for Chase-issued cards (424242)

BIN checks should only involve the first 6–8 digits. Never transmit or store the full PAN. Use this endpoint to identify the issuer and network to adjust 3DS routing, fraud scoring, or fee estimates.

• Endpoint: POST https://www.bankdatastack.com/api/v1/bin/validate
• Body: {"value": "424242"}
• Response fields you’ll use: valid, bank, country (optionally city/branch if available)

Combine BIN validation with device and velocity signals; do not rely on BIN alone for high-risk decisions.

IBAN notes for Chase customers

The United States does not use IBAN. If a user claims to have a U.S. IBAN for a Chase account, that is incorrect. For international receiving accounts outside the U.S., you may encounter IBANs such as the fixture GB82WEST12345698765432, which validates IBAN structure and country rules but does not map to a U.S. Chase account.

Use the IBAN endpoint to ensure the string is well-formed and country-valid. If you expect a Chase U.S. account and receive an IBAN, prompt the user for a U.S. routing number and account number instead.

Handling “not found” and edge cases

• Not found vs invalid: Some identifiers fail structural rules (invalid length/checksum). Others pass structure but don’t map to a known bank in the dataset (not found). In both cases, treat the result as non-routable until corrected.
• Stale instructions: Beneficiary templates can go stale. Re-validate before each new transfer initiation to catch institution or branch updates.
• Partial BINs: Merchants sometimes send 8-digit BINs. Support both 6 and 8; never request the full PAN.
• IBAN country mismatch: If the payer’s country selection disagrees with IBAN country code, force a correction to prevent return fees.

Caching, retries, and observability

• Caching: Cache positive validations keyed by the identifier with a short TTL (e.g., 24–72 hours) to reduce latency and cost. Avoid long-lived caches; bank records can change.
• Negative caching: Use shorter TTLs (e.g., 1 hour) for failures so users can fix typos and re-submit quickly.
• Idempotency: Your validation calls are read-only; use client-side idempotency to de-duplicate repeat validations from the same form step.
• Retries: Implement exponential backoff on network failures. Do not retry on valid: false since that indicates a definitive validation outcome.
• Logging: Log input, valid flag, and normalized bank name/country. Redact or tokenize any sensitive account identifiers outside the scope of BIN.

How to slot these checks into your Finance flows

Onboarding (KYB/KYC for payout recipients)

• Step 1: User enters SWIFT or routing. Immediately call the corresponding validate endpoint.
• Step 2: If valid is true and bank includes “JPMorgan Chase Bank, N.A.” for our Chase-specific routes, show a confirmation banner.
• Step 3: Persist input + normalized bank fields to your beneficiary profile for audit.

Payment initiation (ACH/wire)

• Validate the routing number (021000021 example) and show bank, city, country prior to submission.
• For cross-border, validate CHASUS33 and ensure the country aligns with the currency rail you plan to use.

Card acceptance and fraud screening

• Validate the BIN (424242) to confirm issuer and country prior to AVS/3DS decisions.
• Combine BIN country with IP and billing-country mismatches to adjust risk scoring.

Additional examples you can run

Routing validation payload

{
"value": "021000021"
}

IBAN validation payload

{
"value": "GB82WEST12345698765432"
}

BIN validation payload

{
"value": "424242"
}

All three use the same header and POST method described earlier. For the full field catalog and any optional metadata your plan may include, refer to the Documentation.

Plan, trial, and key management

• Starter plan: $49.99/month
• Trial: 7-day trial available
• API keys: Keep keys server-side; never expose them in client-side code or mobile apps.

You can get started quickly, test the four fixtures above in a lower environment, then wire the checks into your Finance flows. Register for an API key to begin.

FAQ

Does Chase use IBAN for U.S. accounts?
No. The United States does not use IBAN. For domestic U.S. Chase accounts, use the routing number (e.g., 021000021) and account number.

What does a “valid: true” response guarantee?
It confirms the identifier is properly formed and mapped to a known institution profile (bank, city, country). You should still confirm beneficiary names and account numbers as part of your own KYC/KYB process.

How should I handle BIN privacy?
Store only the BIN (first 6–8 digits) if operationally necessary. Never store or log the full card PAN in your systems or traces.

What if the validation returns not found?
Block the submission and ask the user to correct the value. Not found indicates the identifier is unassigned or not recognized in the reference set.

Can I cache validation results?
Yes—cache positives for a short TTL (24–72 hours) and negatives for a shorter TTL (around 1 hour) to balance freshness with performance.

Ready to validate Chase identifiers in your Finance stack? Get your key and start testing today: Register.