Chase Bank (Routing 021000021, BIN 411111, Visa, Credit, New York NY, USA, SWIFT CHASUS33) BIN API

You need to programmatically confirm that a payment card claiming to be a Chase Bank Visa credit card (BIN 411111) and a payout rail (ACH via routing 021000021) actually map to JPMorgan Chase before you accept or send funds. By the end of this guide you will validate the Chase BIN in code, cross-check the bank’s US routing number and CHASUS33 SWIFT, understand what “not found” means, and know how to cache reference data safely in a production flow.

What you can verify for Chase in one workflow

BankDataStack lets you validate several identifiers commonly used with Chase Bank in the United States:

• Card BIN: 411111 (Visa, Credit). This is the first digits of a card number used to identify the issuing bank and product family. You should never store or log the full PAN.
• US ABA Routing Number: 021000021. This is used for domestic ACH/Wire in the US.
• SWIFT/BIC: CHASUS33. This identifies JPMorgan Chase Bank, N.A. for international transfers.
• IBAN: The USA does not use IBAN. You can still validate IBANs for other countries (e.g., GB82WEST12345698765432) when onboarding non-US beneficiaries.

The same REST pattern applies to all identifiers: POST to a validate endpoint with your key, get JSON describing the institution and whether the identifier is active and usable for the intended rail.

Endpoint pattern and authentication

Use POST requests to one of the following endpoints, substituting the path for the identifier you are validating:

• /api/v1/bin/validate
• /api/v1/routing/validate
• /api/v1/swift/validate
• /api/v1/iban/validate

All requests require your API key in the X-API-Key header and a JSON body containing the identifier. See the Documentation for the exact body fields per identifier. The same response shape is used across endpoints: a top-level status and a data object describing the matched record.

Validating the Chase BIN (411111) for Visa Credit

A BIN (Bank Identification Number) is typically the first 6 to 8 digits of a card PAN and identifies the issuer, card brand (e.g., Visa), product type (debit/credit/prepaid), and sometimes region. For PCI reasons you should only transmit the BIN, never the full PAN, expiry, or CVV to your reference data service.

When a user enters a card, strip the first six (or eight) digits to form the BIN and call the BIN validate endpoint. Match the returned issuing bank and brand against your business rules. For example, if you only support Visa credit from US issuers, you can check that the BIN aligns with Chase Bank, Visa, and Credit before you run an authorization.

Python example: validate BIN 411111

import json
import requests

API_KEY = "YOUR_API_KEY"
BASE_URL = "https://www.bankdatastack.com/api/v1"

def validate_bin(bin_number: str):
url = f"{BASE_URL}/bin/validate"
payload = {"bin": bin_number}
headers = {
"X-API-Key": API_KEY,
"Content-Type": "application/json"
}
resp = requests.post(url, headers=headers, json=payload, timeout=10)
resp.raise_for_status()
data = resp.json()
# Use only documented fields: top-level status and data payload
if data.get("status") != "success":
raise ValueError("BIN validation did not succeed")
return data.get("data", {})

if __name__ == "__main__":
# BIN for Chase Bank Visa Credit from the title context
bin_info = validate_bin("411111")
# Example usage: validate issuer name/brand/type from the payload your account is configured to return
# Keep logging minimal; never log full card data
print(json.dumps({"bin_lookup_received": bool(bin_info)}, indent=2))

Integrate this into your card onboarding or pre-auth step. If the BIN record indicates Chase as the issuer, brand Visa, and product Credit, you can proceed. If “not found” or the attributes conflict with user input, decline early or route to manual review.

Official routing validation example for JPMorgan Chase Bank, N.A.

Before initiating an ACH debit/credit to a Chase account, verify that the ABA 021000021 is valid and active for ACH. Use the live example below exactly as shown.

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

{
"status": "success",
"data": {
"routingNumber": "021000021",
"paymentType": "ach",
"name": "Jpmorgan Chase Bank, Na",
"addressFull": "Tampa, FL",
"street": "3RD FLOOR",
"city": "Tampa",
"state": "FL",
"zip": "33610",
"type": "Main Office",
"phone": "813-432-3700",
"active": true,
"lastUpdated": "2026-10-01",
"address": "3RD FLOOR"
}
}

How to use these fields:

• routingNumber and paymentType: Echo what was validated. Use paymentType to ensure you are checking the correct rail (ach vs wire).
• name: JPMorgan Chase Bank, Na confirms the institution. Use this to display a “verified bank” badge to operators.
• active: Gate your ACH attempt on this boolean. If false or missing, do not send the payment.
• type and address fields: Useful for audit logs or when your ops team needs to verify routing metadata with a counterparty.
• lastUpdated: Helps decide your cache freshness window.

Validating the CHASUS33 SWIFT for international payouts

SWIFT/BIC codes are 8 or 11 characters. CHASUS33 is 8 characters (bank code CHAS, country US, location 33). For cross-border wires to Chase in New York, this code routes to JPMorgan Chase Bank, N.A. While you can verify CHASUS33 via the SWIFT endpoint, the USA does not use IBAN; for US beneficiaries you will collect account and routing numbers instead.

In your beneficiary onboarding, if the user enters a SWIFT code for Chase, call the SWIFT validate endpoint before allowing them to proceed. If the response is not found or mismatches the declared bank/country, require correction.

Putting it together in a payment and onboarding flow

Combine BIN, routing, and SWIFT checks to catch data entry errors and basic fraud before you reach authorization or settlement steps:

1. Card onboarding (Visa Credit, BIN 411111):
   • Extract the BIN (first 6–8 digits) and call /bin/validate.
   • Verify brand is Visa and product is Credit. If issuer is Chase as expected, continue.
   • Never store or log the full PAN; at most store BIN and last4 for support.
2. US bank account onboarding (ACH via 021000021):
   • Call /routing/validate with payment_type set to ach.
   • Confirm active is true and the institution name matches Chase.
   • Proceed to micro-deposit verification or instant account verification as applicable.
3. International payout setup (SWIFT CHASUS33):
   • Call /swift/validate and check country code is US and bank is JPMorgan Chase Bank, N.A.
   • Reject if the code is not found or points to a different bank/region than declared.

Identifier formats, checksums, and what “not found” means

• BIN format: 6–8 digits. No checksum in the BIN itself; card PANs use the Luhn check across the full number, which you must not forward to reference services. Only submit the BIN prefix.
• US routing numbers: 9 digits with a checksum. The validation endpoint confirms structure and returns institution metadata and active status for the rail you specified.
• SWIFT/BIC: 8 or 11 alphanumeric characters. The 8-character form references the primary office.
• IBAN: Country-specific lengths and checksums. The USA does not use IBAN. Use IBAN validation only for non-US accounts, such as GB82WEST12345698765432 from the docs.

“Not found” typically indicates any of the following:

• The identifier is mistyped or has an invalid checksum/format (routing/IBAN).
• The identifier is unassigned or not in the reference dataset (e.g., a BIN that does not map to a known issuer).
• The identifier is valid historically but inactive for the specified rail (e.g., an ACH-inactive routing number).

Handle “not found” by rejecting the attempt, asking the user to re-enter details, or escalating to manual review. Do not silently autocorrect identifiers in production.

Caching, data freshness, and operational guardrails

Reference data changes infrequently but not never. Recommended approach:

• Cache positive validations keyed by identifier and rail (e.g., routing:021000021:ach) for 7–30 days.
• Respect lastUpdated from responses where provided to tune cache TTLs. If your cached record is older than the lastUpdated date, refresh immediately.
• Cache negative lookups (not found) for a short window (e.g., 1–4 hours) to prevent repeated bad traffic while allowing for late data additions.
• Log only minimal fields needed for support: identifier, status, institution name, and timestamp. Never log full card PANs; a BIN is sufficient for reference.

Error handling and SLA-aware retries

For network errors or 5xx responses, implement exponential backoff and a small retry budget (e.g., 2–3 quick retries within 1–3 seconds total). For 4xx errors, treat them as terminal except for 429, where you should back off and retry after the suggested window if provided by headers. Keep per-request timeouts short (5–10 seconds) to avoid stalling checkout or payment submission flows.

Compliance notes: PCI and PII in BIN lookups

Never send full PANs, CVVs, or expiry to a reference data service. BIN-level data is not cardholder data under PCI DSS, but treat it as sensitive operational data. Avoid storing the combination of BIN and user PII in logs. For ACH and SWIFT checks, you will handle PII (names, addresses) elsewhere; the validate endpoints require only the identifiers.

Comparing identifiers used with Chase

Pricing, keys, and getting started

BankDataStack offers a Starter plan at $49.99/month with a 7-day trial. To start validating Chase identifiers in your sandbox and then in production, create an account and generate your API key. Keep your key server-side and rotate it periodically per your security policy.

Use the Register link to get an API key and follow the step-by-step Documentation to wire up POST /api/v1/{routing|bin|iban|swift}/validate in your app.

End-to-end example flow for Chase card-to-bank payouts

Consider a marketplace that needs to accept a customer’s Chase Visa card, then later pay out to a Chase bank account:

1. At card add:
   • Extract BIN 411111 from the entered PAN; call /bin/validate.
   • If the BIN issuer is Chase, brand Visa, type Credit, label the payment method accordingly.
   • Tokenize and store only the token, BIN, and last4 (no PAN, no CVV).
2. At bank add:
   • Collect routing and account numbers. Call /routing/validate with 021000021 and payment_type=ach.
   • Confirm active=true; warn operators if active=false or name mismatch.
3. At international payout add (if needed for cross-border):
   • Collect SWIFT CHASUS33; call /swift/validate.
   • If not found or mismatched country, block and request correction.
4. Before funds movement:
   • Re-check cached validations if older than your TTL or older than lastUpdated, refresh as needed.
   • Proceed with authorization or ACH file creation only when validations pass.

Operational notes that save time

• Timezones and timestamps: When you store lastUpdated and your validation timestamp, normalize to UTC. This avoids confusion for ops teams reviewing logs across regions.
• Partial outages: Keep a degraded mode that allows previously validated identifiers (within TTL) to pass while new identifiers are queued until validation service returns.
• Pagination/batching: For bulk beneficiary imports, batch validations on your side and rate-limit requests with short sleeps. Store results by identifier to deduplicate repeated checks.
• Idempotency: Make your internal validation write operations idempotent keyed by identifier and day, so retries do not create duplicate audit entries.

FAQ

Does BIN validation require me to send the full card number?
No. Send only the BIN (first 6–8 digits). Never transmit or store full PAN, CVV, or expiry for reference data checks.

What if the routing number 021000021 is valid but active=false?
Do not initiate ACH. Ask the user to confirm their routing number or select a different rail (wire) and validate that rail separately.

Can I validate an IBAN for a Chase account in the USA?
No. The USA does not use IBAN. Use routing and account numbers for US accounts, and SWIFT for international wires.

How should I handle “not found” for BIN 411111?
Treat it as a failure to verify the issuer. Do not attempt authorization until the user provides a card with a BIN that resolves to an expected issuer/brand/type.

Is there a trial and how do I get an API key?
Yes. There’s a 7-day trial on the Starter plan ($49.99/month). Create your account and generate a key via the Register page.

Ready to ship BIN, routing, and SWIFT checks for Chase in your onboarding and payment flows? Start your 7-day trial and get your key now, then follow the Documentation to integrate POST /api/v1/{routing|bin|iban|swift}/validate in under an hour.