SWIFT Code CITIUS33

You need to verify that the SWIFT/BIC code CITIUS33 actually belongs to Citibank N.A. in New York before releasing a cross-border wire. By the end of this guide, you will validate CITIUS33 using the BankDataStack API, parse the result in code, and integrate it into your payment or onboarding flows with the right checks, caching, and error handling.

What CITIUS33 identifies and where it’s used

CITIUS33 is a SWIFT/BIC code. SWIFT codes route international transfers through the global SWIFT network, identifying the receiving bank and location. A valid match allows your system to auto-fill bank details and reduce misrouted payments.

Structure highlights:

• Length: 8 or 11 characters. CITIUS33 is 8 characters.
• Components: bank code (CITI), country code (US), location code (33), and optionally a branch code (3 characters) if present.

When you validate CITIUS33 with BankDataStack, you’ll receive the issuing bank, city, and address, which you can display to a user or use in automated controls to confirm the destination before initiating a wire.

Validate CITIUS33 via the API

Send a POST request to the SWIFT validate endpoint with your API key and the code to check. This is a single-call verification designed for pre-payment validation and onboarding KYC/KYB flows.

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

A successful validation returns data about the bank and a breakdown of the SWIFT components:

{
    "status": "success",
    "message": "SWIFT code CITIUS33 is valid",
    "data": {
        "swiftCode": "CITIUS33",
        "bank": "CITIBANK N.A.",
        "city": "New York",
        "branch": "Head Office",
        "address": "388 GREENWICH STREET NEW YORK,NY NEW YORK,NY 10013 UNITED STATES OF AMERICA",
        "postCode": "10013",
        "country": "United States",
        "countryCode": "US",
        "breakdown": {
            "swiftCode": "CITIUS33",
            "bankCode": "CITI",
            "countryCode": "US",
            "locationCode": "33",
            "codeStatus": null,
            "branchCode": null
        }
    }
}

Field usage in your app:

• data.bank, data.city, data.address: Display to the user so they can confirm destination bank details before submission.
• data.countryCode: Route flows based on jurisdiction (e.g., US vs. EU compliance steps).
• data.breakdown.bankCode and data.breakdown.locationCode: For downstream analytics or rule checks, such as flagging unexpected bank/location pairings.
• status and message: Drive UI outcomes (success checkbox, inline error, or retry prompts).

See the full API surface in the Documentation. To try this with your own key, start with a 7-day trial on the Starter plan ($49.99/mo after trial) and call the endpoint directly.

Using the validation in payment and onboarding flows

Insert SWIFT validation at the moment a user provides their recipient bank details or uploads a payment file. This prevents costly rejections and re-keys.

• Onboarding: As soon as a business enters CITIUS33, validate it and display “CITIBANK N.A., New York” to confirm. Store the validated SWIFT code and country code with the customer’s profile.
• Payment initiation: Before creating the SWIFT MT/MX payment instruction, re-validate the SWIFT to catch any typos. Use data.address and postCode if you need to enrich KYC screening or apply country-specific restrictions.
• Fraud/compliance: Cross-check countryCode US with the expected beneficiary country. If there’s a mismatch with other beneficiary data, require additional verification.

Python example: validate CITIUS33 before a wire

This example posts to the same endpoint, checks success, and extracts the bank name, address, and country code for your workflow logic.

import json
import sys
import urllib.request

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

payload = {"swift": "CITIUS33"}
data = json.dumps(payload).encode("utf-8")

req = urllib.request.Request(API_URL, data=data, method="POST")
req.add_header("X-API-Key", API_KEY)
req.add_header("Content-Type", "application/json")

try:
with urllib.request.urlopen(req, timeout=10) as resp:
body = resp.read().decode("utf-8")
result = json.loads(body)
except Exception as e:
print(f"Network or HTTP error: {e}", file=sys.stderr)
sys.exit(1)

status = result.get("status")
message = result.get("message", "")

if status != "success":
# Handle invalid or unknown SWIFT code
print(f"Validation failed: {message}")
sys.exit(2)

data = result.get("data", {})
bank = data.get("bank")
city = data.get("city")
country_code = data.get("countryCode")
address = data.get("address")
swift_code = data.get("swiftCode")

print(f"Validated SWIFT: {swift_code}")
print(f"Bank: {bank} — {city}, {country_code}")
print(f"Address: {address}")

# Example branching: only allow payouts to US banks for this corridor
if country_code != "US":
print("Destination not allowed for this corridor.")
sys.exit(3)

# Persist minimal reference attributes for audit/logging
validated_record = {
"swiftCode": swift_code,
"bank": bank,
"city": city,
"countryCode": country_code
}
print("Store reference:", json.dumps(validated_record))

In production, wrap this call with retry logic on transient timeouts and capture result.status and result.data for audit. If status is not success, do not queue the payment; surface message to the user and allow correction.

Identifier formats and checksums: what matters for validation

SWIFT/BIC:

• Format: 8 or 11 characters.
• Composition: 4-letter bank code, 2-letter ISO country code, 2-character location code, optional 3-character branch code.
• Checksum: None in SWIFT itself; validation is structural and directory-based (i.e., checking against authoritative reference data).

Contrasting with other finance identifiers you may validate alongside a SWIFT in your flows:

• IBAN: Includes a country-specific format and a mod-97 checksum (the USA does not use IBAN).
• US Routing (ABA): 9 digits with a checksum algorithm specific to ABA format.
• Card BIN: The first digits of a card number that identify the issuer; never store full PANs.

In a multi-step payment capture flow, validate the SWIFT first, then validate local account/routing or IBAN as applicable. For cards, restrict yourself to BIN-level insights for routing and risk; do not store full PANs.

Handling errors, not found, and edge cases

• Not found: If the service cannot match the SWIFT code to a published bank entry, treat it as invalid. Ask the user to re-enter or contact their bank for the correct BIC.
• Formatting errors: Reject inputs that are not 8 or 11 characters or violate allowed alphanumeric composition before sending to the API. This saves a network round trip.
• Country-specific rules: Use data.countryCode to decide if additional fields are required. Example: The USA does not use IBAN, so avoid asking US counterparties for one.
• Duplicative validation: For recurring beneficiaries, cache a positive validation and skip re-validating unless the user edits the SWIFT or your cache expires.

Caching and performance

Because bank reference data is relatively stable, you can cache a successful validation of CITIUS33 for a reasonable TTL to reduce latency and cost:

• Client-side/UI: Cache per-session results to avoid repeat calls while a user edits a form.
• Server-side: Cache positive validations for 24–72 hours. Invalidate if the beneficiary record changes or if you receive a payment rejection indicating stale details.
• Idempotency: For batch uploads, de-duplicate identical SWIFT codes to validate once and fan out the result to multiple rows.

Always persist the normalized value from data.swiftCode to ensure consistent matching across your systems. Store only the reference attributes you need (e.g., bank, city, countryCode), not user-entered free text.

Security and compliance notes

• PII minimization: Only store what you need for audit and re-use; the API returns reference data suitable for logging.
• Card data: A BIN is only the first digits of a PAN. Never store full card numbers in your application logs or database unless you have explicit PCI scope and controls.
• Transport: Use HTTPS only. Keep your BankDataStack API key in server-side configuration or a secret manager.

Getting access and pricing

You can start validating SWIFT codes like CITIUS33 with a 7-day trial on the Starter plan ($49.99/month after the trial). Create an account to obtain YOUR_API_KEY and call the endpoint shown above. See endpoint details and field definitions in the Documentation, and sign up here: Register.

FAQ

Is CITIUS33 enough to send a payment?
A valid SWIFT/BIC is required for international wires, but you also need the beneficiary’s account number (or IBAN where applicable) and beneficiary name. Use the SWIFT validation to confirm the destination bank before you build the payment instruction.

Does the USA use IBAN?
No. The USA does not use IBAN. For US banks, use SWIFT for international routing and US routing numbers (ABA) for domestic transfers.

How should I handle a “not found” result?
Treat it as invalid. Prompt the user to recheck the code or select the bank from a supported list. Do not queue the payment until the SWIFT validates successfully.

How long should I cache a validated SWIFT like CITIUS33?
A 24–72 hour server-side TTL is typical for stable bank reference data. Re-validate if the beneficiary record changes or if a payment is rejected for bank detail issues.

Can I validate other identifiers with the same API?
Yes. The same base path supports validation of routing numbers, IBANs, and BINs via their respective endpoints. Keep SWIFT validation for BICs and remember not to store full card numbers—only BIN-level data when working with cards.

Ready to integrate SWIFT validation for CITIUS33 and beyond? Get your API key and start your trial here: Register. For implementation details, see the Documentation.