SWIFT CHASUS33 API in Python

You need to automatically validate the SWIFT/BIC code CHASUS33 before releasing a wire payment or onboarding a US counterparty. By the end of this article, you will call the BankDataStack SWIFT validation endpoint from Python, verify CHASUS33, interpret the response in your payments flow, handle “not found” outcomes safely, and cache results to reduce latency and API calls.

What CHASUS33 represents and why to validate it

CHASUS33 is a SWIFT/BIC identifier. SWIFT codes route international payments by identifying a financial institution and, optionally, a specific branch. Validating a SWIFT code prior to initiating a cross-border transfer reduces straight-through-processing failures, speeds up operations reviews, and adds a basic layer of protection against mistyped or stale bank details.

At a high level, a SWIFT code has the following structure:

• 4 letters: bank identifier
• 2 letters: ISO 3166-1 alpha-2 country code
• 2 letters or digits: location code
• Optional 3 letters or digits: branch code (for an 11-character SWIFT)

CHASUS33 is 8 characters long (no explicit branch). The code’s passport-level checks (length, character sets, and country code syntax) are necessary but not sufficient. In production you also want a registry-backed confirmation that the code exists and is currently assigned. That is the role of BankDataStack’s SWIFT validation API.

Endpoint overview: validate a SWIFT code

The BankDataStack API exposes a single validation endpoint for each identifier family. For SWIFT/BIC, you POST the code to:

POST https://www.bankdatastack.com/api/v1/swift/validate

Authentication is via an API key header:

• X-API-Key: YOUR_API_KEY

Request body is JSON containing the code to validate. BankDataStack focuses on returning core reference fields you can use for routing and compliance gates. You’ll see a boolean validity indicator and, when available, the associated institution and location details. The exact fields you use will depend on your flow; keep your integration minimal and defensive.

Complete curl request for CHASUS33

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 '{
"swift": "CHASUS33"
}'

Replace YOUR_API_KEY with your key from BankDataStack. If you don’t have one, start a 7-day trial on the Starter plan ($49.99/mo after trial) here: Register.

Python example: validate CHASUS33 in your flow

The following Python snippet posts CHASUS33 to the validation endpoint and demonstrates how to wire the response into your payment-release logic:

import os
import json
import requests

API_KEY = os.getenv("BANKDATASTACK_API_KEY", "YOUR_API_KEY")
URL = "https://www.bankdatastack.com/api/v1/swift/validate"

def validate_swift(swift_code: str) -> dict:
headers = {
"Content-Type": "application/json",
"X-API-Key": API_KEY
}
payload = {"swift": swift_code.strip().upper()}
resp = requests.post(URL, headers=headers, data=json.dumps(payload), timeout=10)
resp.raise_for_status()
return resp.json()

def can_release_wire(swift_code: str) -> bool:
data = validate_swift(swift_code)
# Minimal, defensive gating: only proceed if the code is valid.
# Use institution/location fields if present for further policy checks.
if not data.get("valid"):
return False

# Optional policy checks if the API returns these fields:
# country = data.get("country")
# city = data.get("city")
# bank = data.get("bank")
# Example: enforce allowed corridors or deny certain countries.
# if country not in {"US", "GB", "DE"}:
# return False

return True

if __name__ == "__main__":
swift = "CHASUS33"
try:
details = validate_swift(swift)
print("Lookup response:", json.dumps(details, indent=2))
if details.get("valid"):
print(f"SWIFT {swift} is valid. Proceeding with payment release checks.")
else:
print(f"SWIFT {swift} is not valid or not found. Do not release the payment.")
except requests.HTTPError as e:
print("HTTP error calling BankDataStack:", e)
except requests.RequestException as e:
print("Network/timeout error calling BankDataStack:", e)

Sample JSON response and field usage

Below is a realistic, minimal example to illustrate the response shape for CHASUS33. Field names shown are representative of the SWIFT validation output. Values are illustrative where not otherwise provided, and your production integration should read the fields defensively.

{
"valid": true,
"swift": "CHASUS33",
"bank": null,
"branch": null,
"city": null,
"country": null
}

How to use these fields in practice:

• valid: Gate your workflow. If false, stop the wire or prompt for correction.
• swift: Echo the normalized code into your logs and payment metadata.
• bank, branch, city, country: When present, display to your ops team for a quick visual cross-check; optionally enforce corridor policies (e.g., allowed destination countries) or match counterparty paperwork during onboarding.

Because validation results change infrequently, cache known-good responses (e.g., for 24 hours or your risk team’s chosen TTL) to reduce latency and API calls. If your cache is cold or stale, re-query the API before releasing the payment.

Where this fits in your payments and onboarding flow

Most teams invoke SWIFT validation during both data entry and payment release:

• Onboarding: When a counterparty submits a SWIFT/BIC, validate it synchronously and show friendly, actionable errors if invalid. Optionally display institution and country back to the user for confirmation.
• Payment preparation: Before generating MT103 or ISO 20022 payment instructions, check the SWIFT again in case details changed since onboarding.
• Ops review: Surface the normalized SWIFT and any associated bank/location fields to your risk or treasury operators alongside sanctions and fraud checks.

If your platform supports multiple identifier types, you can centralize the pattern using the related validation endpoints for routing numbers, IBANs, and BINs with the same POST semantics and header.

Other identifiers you may validate alongside SWIFT

BankDataStack validates several identifier families used in payments and card processing. This table summarizes how they differ and how to handle them in your code. The USA does not use IBANs for domestic payments.

Practical request/response tips

• HTTP method: Always POST to the validate endpoint family: /api/v1/swift/validate.
• Auth: Provide X-API-Key in the header. Keep keys out of client-side code and logs.
• Timeouts: Use short HTTP timeouts (e.g., 5–10 seconds) and retry with backoff on transient failures. Do not retry on 4xx validation failures.
• Normalization: Uppercase the SWIFT code and trim whitespace before sending.
• Not found or invalid: Treat valid=false as a hard failure for payment release. For onboarding, prompt the user to correct it. Do not auto-correct or guess.
• Caching: Store positive validations with a TTL aligned to your risk posture (e.g., 24–72 hours). Invalidate cache when a payment is edited.
• Auditing: Log the normalized code and the boolean validity. Avoid logging PII or full card numbers. For card flows, log only the BIN, never the full PAN.

End-to-end flow example with CHASUS33

1) Collect and normalize input

Your UI captures a SWIFT code. Normalize to uppercase and strip spaces. For CHASUS33, this yields CHASUS33.

2) Validate via BankDataStack

POST to /api/v1/swift/validate with the normalized code and your API key. If the response has valid=false, block the flow and show an inline error message. If true, proceed.

3) Optional enrichment checks

If the response includes country or city, confirm it matches the counterparty’s paperwork. If your policy restricts certain corridors, enforce them now. Keep these checks tolerant of missing optional fields.

4) Cache the result

Cache the successful response keyed by the SWIFT code. Use a firm TTL so changes in registry data propagate within a reasonable time window.

5) Release the payment

When composing cross-border payment messages (e.g., MT103 or ISO 20022), include the normalized SWIFT. Keep a minimal audit record: code, timestamp, and validation outcome.

Testing with official fixtures

Use these known fixture values during development to exercise each validator route consistently:

• SWIFT: CHASUS33
• US Routing: 021000021
• IBAN: GB82WEST12345698765432 (note: the USA does not use IBANs domestically)
• Card BIN: 424242 (always test with BINs only; never log or store full PANs)

All validators share the same POST semantics and X-API-Key header; only the path and JSON payload field name differ.

Error handling and “not found” outcomes

A “not found” or invalid result generally means one of the following:

• Typo or formatting issue (wrong length or characters)
• Code was decommissioned or is not currently assigned
• You attempted to validate a branch format where only the 8-character code is recognized

Treat valid=false as non-retryable for user input until the user changes the value. If you receive an HTTP error (e.g., 5xx), treat it as transient: backoff and retry, and surface a generic error to the user without exposing infrastructure details.

Security, privacy, and logging

• Never store full primary account numbers (PANs). For card use cases, only store and log the BIN (first 6–8 digits) and the minimal metadata required by your policies.
• Restrict access to your API key, rotate on a regular schedule, and use environment variables or a secrets manager in CI/CD.
• Log only what you need for audit: the normalized identifier, validation outcome, and a timestamp. Avoid sensitive personal data.

Going live and pricing

You can start with a 7-day trial on the Starter plan ($49.99/mo thereafter). Create your key and run the exact curl and Python snippets in this article against CHASUS33. For additional details on request fields and other identifier validators, review the Documentation.

FAQ

Does the USA use IBAN for domestic payments?
No. The USA uses routing numbers (ABA) for domestic ACH and wires. IBANs are used in many other countries; you can validate them with the IBAN endpoint, but do not request IBANs from US customers for domestic transfers.

What does a “valid=false” response mean for CHASUS33?
It means the code failed structural or registry-backed validation. Do not release the wire; prompt the user to correct the SWIFT or verify with the counterparty.

Should I store the SWIFT validation response?
Yes, cache positive results with a sensible TTL to reduce latency and API calls. Keep only minimal, non-sensitive metadata needed for audits.

Is there a checksum for SWIFT codes?
No arithmetic checksum like IBAN’s Mod-97 exists for SWIFT. Validation relies on structure and registry data. Use the API instead of trying to whitelist from static lists.

Can I validate routing numbers, IBANs, and BINs with the same API?
Yes. BankDataStack exposes separate validate endpoints for routing, IBAN, and BIN with the same POST semantics and authentication header. Use the correct path for each identifier family.

Ready to validate CHASUS33 and ship your Python integration? Create an API key and run the examples above with your environment: Register. For full reference information and additional identifier types, see the Documentation.