API for Routing Number 131000104 – Sterling National Bank (New York, NY) Lookup

You need to send or receive a U.S. payment and want to be 100% sure the routing number on file is valid and points to the expected bank and location. By the end of this guide, you will know exactly what routing number 131000104 represents, how routing numbers work for ACH and wire transfers, and how to verify this number automatically using the BankDataStack Routing Number API in your onboarding and payment flows.

What routing number 131000104 represents

Routing number 131000104 corresponds to Sterling National Bank located in New York, NY. If a customer or counterparty supplies 131000104 as their routing number, your systems should interpret it as an instruction to route U.S. domestic payments through Sterling National Bank in New York.

Developers validating bank details should confirm three essentials before creating or executing a transfer:

• The routing number is structurally valid (9 digits with a valid checksum).
• The number maps to the expected bank name and city/state: Sterling National Bank, New York, NY.
• The number supports the transfer network you plan to use (e.g., ACH or wire) and is currently active.

How U.S. routing numbers work and why they matter

A U.S. bank routing number (also called an ABA or RTN) is a 9-digit identifier that directs domestic payments to the right financial institution. It is used with a deposit account number to identify the destination for ACH credits/debits and wire transfers.

Key points for developers and operations teams:

• Format and checksum: Routing numbers are 9 digits. A checksum calculation on the first eight digits must yield the ninth; this catches common transcription errors.
• Payment networks: Many routing numbers work for both ACH and wire, but some are specialized. Always check capabilities before initiating a transfer.
• Bank mergers and status: Banks can merge or retire routing numbers. You should verify that a number is active and reflects the expected legal bank name and location.

Where routing numbers fit in ACH vs. wire transfers

When preparing a domestic transfer, your flow typically needs:

• For ACH: routing number, account number, account type (checking/savings), and account holder name. ACH is batch-processed and lower cost, often settling next business day.
• For wire: routing number for domestic U.S. wires, plus account number and beneficiary details. Wires are real-time gross settlement or same day with higher fees.

In both cases, the routing number instructs the clearing system which bank to credit or debit. Validating that 131000104 resolves to Sterling National Bank in New York, NY protects you from misroutes and reduces returns and operational overhead.

Validate 131000104 with the BankDataStack Routing Number API

BankDataStack offers a Finance-focused reference data API for routing numbers, SWIFT/BIC codes, IBANs, and card BINs. The Routing Number API lets you look up 131000104 and confirm the issuing bank and location in real time, returning clean JSON for easy integration.

You can learn more and request an API key on the homepage: https://www.bankdatastack.com. Once you have an API key, your application can verify the routing number during onboarding, payout setup, or immediately before posting an ACH or wire.

Sample curl request

The following example shows a typical GET request to validate routing number 131000104. Replace YOUR_API_KEY with your actual key.

curl -s -X GET \
"https://www.bankdatastack.com/api/v1/routing/131000104" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Accept: application/json"

Sample JavaScript (Node.js) request

This snippet demonstrates how to call the same endpoint from a server-side Node.js environment and make routing decisions based on the response.

import fetch from "node-fetch";

async function validateRouting(routingNumber) {
const resp = await fetch(`https://www.bankdatastack.com/api/v1/routing/${routingNumber}`, {
headers: {
"Authorization": "Bearer YOUR_API_KEY",
"Accept": "application/json"
}
});

if (resp.status === 404) {
// Not found: treat as invalid or retired
return { valid: false, reason: "not_found" };
}
if (!resp.ok) {
// Handle transient errors with retry or circuit-breaker logic
throw new Error(`Lookup failed with status ${resp.status}`);
}

const data = await resp.json();
// Example field usage shown below; adjust to your schema/needs.
const {
routing_number,
bank_name,
bank_city,
bank_state,
bank_country,
ach_supported,
wire_supported,
active
} = data;

const matchesExpectedBank = bank_name === "Sterling National Bank" && bank_city === "New York" && bank_state === "NY";
const canUseNetwork = ach_supported || wire_supported;

return {
valid: active && matchesExpectedBank && canUseNetwork,
details: data
};
}

// Example usage
validateRouting("131000104")
.then(result => {
if (!result.valid) {
console.error("Routing number failed validation:", result);
return;
}
console.log("Routing number validated:", result.details);
})
.catch(err => {
console.error("Lookup error:", err);
});

Illustrative JSON response

The following JSON shows the kinds of fields your application will receive. Field names are representative for demonstration and the values are illustrative for the routing number discussed in this article.

{
"routing_number": "131000104",
"bank_name": "Sterling National Bank",
"bank_city": "New York",
"bank_state": "NY",
"bank_country": "US",
"address": "New York, NY",
"phone": null,
"ach_supported": true,
"wire_supported": true,
"active": true
}

How to use these fields in your flows:

• routing_number: Echo back for audit logging and to ensure the request matched the user-supplied value.
• bank_name, bank_city, bank_state, bank_country: Cross-check against what the user expects to see (Sterling National Bank, New York, NY, US) and display in your UI for confirmation.
• ach_supported, wire_supported: Decide which rails to enable (e.g., enable ACH credits and same-day wires if both are true).
• active: Block setup or payments if false (retired or inactive identifiers).

Where to place routing validation in your product

Validation is most effective if it happens before you store or use the account details:

• Onboarding: As soon as a business or consumer enters a routing number, auto-lookup and surface the bank name and city/state. Ask the user to confirm it matches their bank.
• Payout setup: If ACH is required, ensure ach_supported is true. If only wire is available, update the UI to reflect expected timing and fees.
• Pre-transfer checks: Revalidate right before initiating high-value or time-sensitive wires to catch recent changes or deprecations.

Practical considerations: formats, checksums, not-found, and caching

Format and checksum: Routing numbers are exactly 9 digits. Before calling the API, reject any input that is not numeric or not length 9. You can optionally perform a checksum pre-check to reduce unnecessary network calls, then rely on the API response for authoritative validation and bank metadata.

“Not found” responses: If the API returns HTTP 404 for 131000104, treat it as unknown or retired. Do not attempt a transfer. Ask the user to re-verify their bank details and provide documentation if needed. Your UI should clearly differentiate “not found” from temporary errors.

Temporary errors: For 5xx or network timeouts, implement a bounded retry (e.g., exponential backoff) and present a non-blocking warning if validation is temporarily unavailable. Avoid posting payments until a lookup succeeds.

Caching: Routing numbers rarely change day-to-day, so caching successful lookups can reduce latency and load. Consider a short TTL (e.g., 24–48 hours) to balance freshness with reliability. In sensitive flows (e.g., wires over a set limit), bypass the cache and re-verify.

Data retention: Only store the routing number and the minimal bank metadata (name, city/state) you need for audit trails and reconciliation. Do not store unnecessary PII in your routing lookup logs.

How routing numbers compare to other Finance identifiers

Developers frequently handle multiple financial identifiers in the same system. Here is a quick comparison to clarify when to use each and how to validate them with BankDataStack.

End-to-end example: onboarding a payee with routing number 131000104

1) Collect and sanitize input

Accept the routing number as a numeric string and strip whitespace and non-digits. Reject if length is not 9.

2) Validate via the Routing Number API

Call the API with the sanitized routing number (e.g., 131000104). If 404, mark invalid and prompt the user to re-enter details. If successful, display “Sterling National Bank, New York, NY” for user confirmation.

3) Check network capabilities

If you plan to credit via ACH, require ach_supported to be true. If a same-day wire is needed, check wire_supported. If neither is true, block the transfer and request alternative instructions.

4) Store minimal metadata

Persist the routing number and essential metadata (bank_name, bank_city, bank_state, active) for audit logs and reconciliation. Avoid storing data not required for operations.

5) Payment execution guardrails

• For ACH: run your standard account number checksum/format checks where applicable, use prenotes if your risk policy requires, and set ACH SEC code appropriately.
• For wire: confirm cut-off times and non-settlement days to avoid delays; your treasury ops may require a final re-lookup for high-value transfers.

Error handling patterns that reduce operational noise

Implement a small but consistent set of outcomes for your support and risk teams:

• valid_confirmed: bank metadata matches, routing number active, network supported.
• invalid_format: not 9 digits or checksum failure before lookup.
• not_found: API returned 404 for the number (treat as invalid or retired).
• temporarily_unavailable: network or 5xx error; retry and surface a non-blocking warning.

Map these outcomes to clear user-facing messages. For example, a not_found should prompt the user to verify their bank name and bring their checkbook or a bank letter, while temporarily_unavailable should suggest trying again in a few minutes without discarding the entered value.

Security and compliance reminders

• Scope and keys: Keep your BankDataStack API key server-side and rotate it periodically. Avoid exposing keys in client-side code.
• PII minimization: Routing number validation does not require sensitive personal data. Log only what is necessary to reproduce support issues.
• Card data: If you also work with card BINs, remember a BIN is only the first 6–8 digits; never store or log full PANs.

Try the BankDataStack Routing Number API

To integrate routing number verification for 131000104 and any other U.S. ABA, get your API key at https://www.bankdatastack.com. With a single GET request, you can confirm the bank name, location, capabilities, and status—right where your users enter their details. Start now and ship a safer payments onboarding flow: Request an API key.

FAQ

Does routing number 131000104 belong to Sterling National Bank in New York, NY?
Yes. It corresponds to Sterling National Bank located in New York, NY. Use the API lookup to confirm bank name, city/state, and whether ACH or wire is supported.

What does a “not found” response mean for a routing number?
It means the identifier is unknown or retired in the reference data. Do not initiate a transfer. Ask the user to re-check their banking details or provide alternative instructions.

Should I cache routing number lookups?
Yes, with a short TTL (for example, 24–48 hours). Routing numbers do not change frequently, but for high-value or time-critical wires, re-validate in real time before posting.

Can a routing number work for ACH but not wire?
Yes. Capabilities can differ by routing number. Always check ach_supported and wire_supported (or their equivalents in your response) before allowing a specific rail.

Do I need to store the full response?
No. Store only what you need: routing number, bank name, and location, plus a boolean that indicates active status and supported networks. Avoid retaining unnecessary personal or sensitive data.