API for SWIFT Code KBANKUS33 – Kookmin Bank (Worcester, United States)

You need to verify the SWIFT code for an international transfer and ensure the payment rails will recognize the destination bank before any funds move. By the end of this guide, you’ll be able to validate the SWIFT code KBANKUS33 for Kookmin Bank in Worcester, United States using BankDataStack’s SWIFT Validator API, parse the response in your app, and wire this check into payment and onboarding workflows to prevent misrouted or rejected cross‑border payments.

Why SWIFT codes matter for cross‑border payments

A SWIFT code (also called a BIC) is the global identifier for a bank or branch used in cross‑border payments. It tells the sending institution where to route the payment message across the SWIFT network. A valid SWIFT code ensures the payment reaches the intended bank, and along with the beneficiary account number, it reduces rejections and repair fees.

KBANKUS33 identifies Kookmin Bank in the United States. In this article, we focus on this specific code and how to verify it programmatically so your payment system can proceed only when the identifier is confirmed.

Quick refresher: SWIFT/BIC format and high‑level checks

SWIFT codes are typically 8 or 11 characters:

• First 4 letters: bank code (letters only)
• Next 2 letters: ISO country code
• Next 2 letters or digits: location code
• Optional last 3: branch code (letters or digits). If omitted, it often refers to the primary office.

KBANKUS33 is an 8‑character SWIFT code. It identifies the bank and its location. While SWIFT codes do not use a modulus checksum like IBANs, validation still includes structural checks (length, allowed characters) and lookup confirmation against current reference data to map the bank, city, and country.

Validating KBANKUS33 with the BankDataStack SWIFT Validator API

BankDataStack provides REST endpoints to look up and validate banking identifiers and return normalized reference data including bank name, branch, city, and country. You can use it to programmatically confirm that KBANKUS33 is a recognizable SWIFT/BIC and retrieve the basics your UI or payment processor needs prior to initiating an international transfer.

Learn more or request access at https://www.bankdatastack.com. If you do not yet have credentials, you can get an API key here: https://www.bankdatastack.com.

Endpoint and request

The example below shows a GET request to look up the SWIFT code KBANKUS33. Replace YOUR_API_KEY with your token.

curl -s https://www.bankdatastack.com/api/v1/swift/KBANKUS33 \
-H "Authorization: Bearer YOUR_API_KEY"

Example JSON response

The following example illustrates the fields you will receive for this lookup. Values are representative of a successful lookup for this SWIFT code.

{
"bic": "KBANKUS33",
"bank_name": "Kookmin Bank",
"branch": "Primary Office",
"city": "Worcester",
"country": "United States"
}

Fields you typically use in your payment flow:

• bic: The SWIFT/BIC code as submitted. Use this to confirm the identifier shown to the user matches the validated record.
• bank_name: The institution name to display in your UI and to store alongside the payment order.
• branch: The branch designation if the SWIFT represents a specific office. If you receive “Primary Office,” assume the main office for routing purposes.
• city and country: For compliance and display, and to help your operators confirm the beneficiary bank’s location for cross‑border rules and cutoffs.

JavaScript example: verify KBANKUS33 before creating a cross‑border payment

This snippet demonstrates a server‑side Node.js call that validates the SWIFT code before you create a payment instruction. Fail closed if the lookup is not successful or returns no match.

import fetch from "node-fetch";

async function verifySwiftAndCreatePayment(swiftCode, beneficiaryAccount, amount, currency) {
const resp = await fetch(`https://www.bankdatastack.com/api/v1/swift/${encodeURIComponent(swiftCode)}`, {
headers: { "Authorization": "Bearer YOUR_API_KEY" }
});

if (!resp.ok) {
// For example: 404 if not found, 401 if unauthorized.
throw new Error(`SWIFT lookup failed: HTTP ${resp.status}`);
}

const data = await resp.json();

// Minimal expected fields from the validator
if (!data || !data.bic || !data.bank_name) {
throw new Error("SWIFT validation returned an incomplete record");
}

// Use validated data in your payment order record
const paymentOrder = {
swift_bic: data.bic,
bank_name: data.bank_name,
branch: data.branch || null,
bank_city: data.city || null,
bank_country: data.country || null,
beneficiary_account: beneficiaryAccount,
amount,
currency
};

// Continue with payment creation logic in your system...
return paymentOrder;
}

// Example call:
verifySwiftAndCreatePayment("KBANKUS33", "1234567890", "1000.00", "USD")
.then(order => console.log("Ready to submit payment:", order))
.catch(err => console.error("Validation error:", err));

How to integrate the validator into onboarding and payment flows

There are two common points where you should validate SWIFT codes like KBANKUS33:

• Beneficiary onboarding: As soon as a user enters a beneficiary bank identifier, validate it and show the bank name and location for confirmation. Store the validated fields with the beneficiary record.
• Payment initiation: Just before creating the cross‑border payment, revalidate the SWIFT code or retrieve it from your cache if still fresh. This ensures up‑to‑date reference data at the moment of sending.

For user experience, display the resolved bank name “Kookmin Bank” and the city/country “Worcester, United States” to help the sender verify they picked the right counterparty bank. If the code is not found, block the next step and prompt the user to correct the entry.

Handling “not found” and other edge cases

When a lookup returns “not found,” it means the identifier is either mistyped, retired, or not present in the current reference dataset. You should:

• Prevent submission of the payment and ask the user to recheck the SWIFT code with the beneficiary.
• Log the attempted code for your ops team to review; many failures are single‑character typos.
• Offer inline guidance: SWIFT codes are 8 or 11 characters, uppercase letters for bank and country codes, and alphanumeric for the last segments.

If the response is successful but some optional fields are blank (for example, no explicit branch), proceed with the primary office details and include bank name, city, and country in your payment record for auditability.

Caching and data freshness

Reference data does not change minute‑to‑minute, but it can change as institutions open, close, or consolidate branches. Practical guidance:

• Cache successful SWIFT lookups locally for 24 hours to reduce latency and API calls. Use the SWIFT code as the cache key.
• On cache hit, reuse the stored bank_name, branch, city, and country. On cache miss or after expiry, requery the API.
• In long‑running payment flows, revalidate at the final submission step if your cached entry is older than your TTL.

Your caching policy should balance performance with the need for fresh data. If your platform processes regulated payments, prefer shorter TTLs and revalidation on submission.

Comparing identifiers: where SWIFT fits next to IBAN, ABA, and BIN

Developers often mix up which identifier is needed in each geography. Use this table as a quick reference for payment and card flows:

For the transfer using KBANKUS33, the SWIFT code identifies Kookmin Bank in Worcester, United States. You will also need the beneficiary account number in the local account format required by the receiving bank.

Operational tips for productionizing the SWIFT check

• Input normalization: Uppercase the SWIFT string and trim whitespace before lookups. Reject lengths other than 8 or 11 characters at the edge.
• UI confirmation: Echo back “Kookmin Bank — Worcester, United States” next to the SWIFT field to minimize user errors.
• Audit trail: Store the validated bic, bank_name, city, and country with a timestamp in your payment record for compliance reviews.
• Error handling: Distinguish between not found (user action required) and network/auth errors (retry or escalate).
• Security: Treat your BankDataStack API key as a secret; call the API from your server, not client‑side web or mobile code.

Putting it together in a payment flow

1) Capture and validate

When a sender inputs the SWIFT code, call the SWIFT Validator API immediately. If KBANKUS33 is returned with Kookmin Bank, show the confirmation and allow the user to proceed. If not found, prevent continuation and guide correction.

2) Prepare the payment instruction

Once KBANKUS33 is validated, combine it with the beneficiary’s account number and payment amount/currency. Attach the normalized bank_name, city, and country to the payment order object that you hand off to your payment processor or internal rails.

3) Final revalidation

At the moment of submission, if your cached validation is older than your TTL, fetch it again. This reduces the risk of using stale reference data on high‑value wires.

4) Post‑submission monitoring

If a payment bounces due to downstream validation, log both the SWIFT you submitted and the resolved bank metadata to help ops diagnose issues and refine UI prompts.

curl and JSON: copy‑paste and ship

Use the following curl command to test the lookup for KBANKUS33 in a terminal. It’s the same endpoint shown above, and the response format is designed to be easy to parse and store.

curl -s https://www.bankdatastack.com/api/v1/swift/KBANKUS33 \
-H "Authorization: Bearer YOUR_API_KEY"

Expected JSON (illustrative values):

{
"bic": "KBANKUS33",
"bank_name": "Kookmin Bank",
"branch": "Primary Office",
"city": "Worcester",
"country": "United States"
}

With these fields, you can display the confirmation to the user, store the resolved bank metadata, and proceed to create a compliant payment order. Visit https://www.bankdatastack.com to learn more about the Finance APIs for bank identifier validation, and get your API key at https://www.bankdatastack.com.

FAQ

Does the validator check for 8 vs 11 character SWIFT codes?
Yes. You should accept both lengths. If you receive 11 characters, the last three usually indicate a branch; 8 indicates the primary office. Your validation logic should allow both but require a record to be found.

What does a “not found” response mean for KBANKUS33?
It means the code could not be matched in current reference data. Treat this as a blocking error for payment submission and prompt the user to reverify the SWIFT code with the beneficiary.

How long should I cache SWIFT lookups?
A practical TTL is 24 hours for most flows. If you operate in high‑risk contexts or submit high‑value transfers, revalidate at the final step even if the cache is warm.

Can I store the full card number if I also integrate BIN lookups?
No. Never store full PANs. BINs represent only the first digits used for issuer identification. Limit storage to BIN and issuer metadata when working with card flows.

What fields do I need to persist from the SWIFT lookup?
Persist bic, bank_name, branch (if present), city, and country alongside your payment order, plus your own timestamp for the validation event.

Validate KBANKUS33 now and wire the check into your onboarding and payments stack. Get an API key from https://www.bankdatastack.com and start preventing misrouted or rejected cross‑border payments with a single call.