You're building a trading platform, a payment processor, or some internal tool that needs to answer a simple question: if a trade happens today, when does it settle?

The naive answer is "T+2" or "T+1" depending on your market. Add two business days. Easy.

Then you discover that "business day" is not a simple concept.

Veterans Day is a trading day on the NYSE—markets are open, trades execute—but it's not a settlement day. DTCC is closed. So a trade executed on Veterans Day doesn't settle T+1 from that day; it settles T+1 from the next settlement day. Your date math needs to distinguish between "trading holidays" and "settlement holidays," which are not the same list.

Then you have a client trading across markets. They're executing a trade in New York and London simultaneously. The settlement date needs to be a business day in both jurisdictions. If the UK has a bank holiday that the US doesn't, settlement shifts. Your code now needs to compute the intersection of two countries' banking calendars.

Then someone asks about FX settlement, which follows yet another calendar (CLS bank holidays). And Middle Eastern markets, where the workweek is Sunday through Thursday. And half-day trading sessions—the NYSE closes at 1 PM the day after Thanksgiving, but is that a full settlement day or not?

This is what fintech developers actually deal with. Not "add two days to a date." A maze of overlapping calendars, jurisdictional rules, and edge cases that will cause settlement failures if you get them wrong.

When the US moved to T+1 settlement in May 2024, it wasn't just American firms that felt it. European firms trading US securities suddenly faced brutal deadlines: allocation by midnight UK time, affirmation by 2 AM UK time. The compressed timeline left almost no room for errors or manual intervention.

Firms that had been calculating settlement dates with spreadsheets or hardcoded holiday lists discovered those approaches don't scale. One missed holiday, one edge case around a long weekend, and trades fail to settle. Failed settlements mean penalties, regulatory scrutiny, and operational chaos.

The firms that handled T+1 smoothly were the ones with robust, automated settlement date calculations that accounted for all the edge cases. The ones that struggled were still doing date math by hand or relying on systems that assumed "business day" was a simple concept.

Let's be specific about the calculations that fintech products require:

Given a trade date, what's the settlement date? This sounds simple until you account for:

• Trading holidays vs. settlement holidays. Markets open doesn't mean settlement happens.

• Multi-market trades. Cross-border transactions need business days in both jurisdictions.

• Weekend variations. Israel's week is Sunday-Thursday. UAE switched to Monday-Friday in 2022, but not all Gulf states did.

• Half-days. Do they count as full business days for settlement purposes? (Usually yes, but not always.)

A payment platform needs to tell users "your transfer will arrive by X date." A trading app needs to show "this trade settles on X." Getting these dates wrong isn't a minor UX issue—it's an operational failure.

Add N business days to a date. Subtract N business days. Count the business days between two dates. These operations sound trivial, but they require knowing:

• Which days are weekends in the relevant jurisdiction

• Which days are banking holidays

• Whether the start/end dates themselves count

Every financial application needs this. Invoice due dates ("Net 30" means 30 business days). Payment processing windows. Regulatory filing deadlines. Loan interest calculations.

Not just "US holidays" but specifically banking holidays. And not just federal holidays—the nuances matter.

Is Juneteenth a banking holiday? (Yes, since 2021.) Is Election Day? (No, despite being a state holiday in some places.) What about the day after Thanksgiving? (Banks are open, but many close early.)

For multi-currency operations, you need banking calendars for every jurisdiction you touch. USD settlement needs US banking holidays. EUR settlement needs TARGET2 holidays. GBP needs UK bank holidays. Each calendar is slightly different.

Most holiday APIs are built for general purposes—telling users when Christmas is, displaying holidays on a calendar widget. They're not built for the specific requirements of financial settlement.

They don't distinguish holiday types. A general holiday API will tell you that Veterans Day is a US holiday. It won't tell you that it's a trading day but not a settlement day. That distinction doesn't matter for a travel app; it's critical for a trading platform.

They don't handle business day calculations. They give you a list of holidays. Computing "T+2 from October 9th, accounting for Columbus Day and the weekend" is left as an exercise for the reader. You end up writing your own date math library on top of their data.

They don't cover the right jurisdictions. CLS bank holidays for FX settlement. TARGET2 holidays for EUR. Hong Kong and Singapore banking holidays for APAC operations. General-purpose APIs often have spotty coverage outside the US and Western Europe.

They update unpredictably. When the UK announced an extra bank holiday for the Queen's funeral, how quickly did your holiday data source reflect it? Fintech can't afford to discover a new holiday when trades start failing.

Many financial firms—even large ones—still maintain holiday calendars in spreadsheets. Someone in operations updates the Excel file every December with next year's holidays. It gets uploaded to a shared drive. Applications read from it.

This works until it doesn't.

The spreadsheet has US holidays but someone forgot to add Singapore when you expanded there. A holiday changes (the UK moving the May bank holiday for the coronation) and nobody updates the file. A new employee doesn't know the spreadsheet exists and hardcodes dates in their application.

Spreadsheet-based holiday management is technical debt that compounds. Every edge case that doesn't fit the spreadsheet's schema gets handled with a workaround. Every workaround is a potential failure point.

We've talked to firms that discovered their spreadsheet had been wrong for months—and only noticed because settlement failures spiked.

We built holiday and business day calculation APIs with financial use cases in mind:

Holiday calendars with type distinctions. We categorize holidays as public holidays, bank holidays, or observances. The business-days endpoint supports different day types: business (excludes weekends + public holidays), banking (excludes weekends + public + bank holidays), and government (excludes weekends + public + authority holidays). Coverage for 230+ countries.

Business day calculations. Add or subtract business days from a date, accounting for weekends and the relevant holiday type. Count business days between two dates. Check if a specific date is a business day. The basic arithmetic that every financial application needs, without making you implement it yourself.

Workweek awareness. Each location has a standard workweek baked into the calculation. Most countries use Monday-Friday. Israel and parts of the Middle East use Sunday-Thursday. The API handles this automatically.

Regional variations. Germany has 16 Länder with different holidays. Australia varies by state. Query a region code (like DE-BY for Bavaria) and get both national and regional holidays in the calculation.

We're a reference data API, not a trading system. There are things we don't do:

Exchange-specific trading calendars. We have banking holidays, not "is the NYSE open right now." Trading hours, half-day sessions, and exchange-specific closures are a different data set. If you need tick-by-tick market data, you need a market data vendor.

Half-day handling. Days like Christmas Eve, when markets close early, are treated as full days in our calculations. If your settlement logic requires half-day precision, you'll need to layer that on top.

Real-time settlement status. We can calculate what the settlement date should be. We can't tell you whether a specific trade actually settled. That's what your prime broker and DTCC are for.

Regulatory filing calendars. SEC filing deadlines, EMIR reporting windows, MiFID obligations—these are regulatory calendars that follow their own rules. We provide the underlying banking holiday data; the regulatory logic sits on top.

FX-specific CLS holidays. CLS Bank has its own holiday calendar that doesn't perfectly match any single country's banking holidays. We don't currently provide CLS-specific data—if you're doing high-volume FX settlement, you may need CLS's own calendar.

Custom holiday inputs. You can't add company-specific holidays to the API calculation. If your firm observes additional closure days, you'll need to handle those in your application logic.

We think it's important to be clear about these boundaries. Settlement date calculation is hard enough without overpromising what the data covers.

A typical settlement calculation workflow looks like this:

Before: Query your internal holiday spreadsheet. Hope it's up to date. Write custom logic to handle multi-market cases. Discover edge cases in production when settlements fail.

After: Call the API with trade date, settlement convention, and relevant jurisdictions. Get back the settlement date. Trust that the holiday data is current because maintaining it is literally our job.

The value isn't in the API itself—any developer can build a date calculation function. The value is in not having to maintain holiday calendars for 230 countries, track when holidays change, handle regional variations, and debug settlement failures that trace back to a missed holiday in your spreadsheet.

Financial applications have low tolerance for errors. A settlement date calculation that's wrong 0.1% of the time sounds good until you realize that's multiple failed settlements per week at any reasonable volume.

We take accuracy seriously:

• We source holiday data from official government publications, not scraped websites

• We track announced changes (new holidays, date shifts) and update promptly

• We distinguish between banking holidays and public holidays where they differ

• We document our data sources and update methodology

We're not claiming perfection—no data source is. But we're explicit about our sources and update practices, so you can evaluate whether our accuracy meets your requirements. If you're operating in a jurisdiction where we're weak, we'd rather you know that upfront than discover it through failed settlements.

You're building a trading platform, a payment processor, a treasury management system, a loan servicing application, or any financial product that needs to calculate dates.

You've been maintaining holiday spreadsheets and you're tired of the operational burden. Or you're building something new and you want to get settlement dates right from the start without implementing your own calendar maintenance.

You understand that "business day" is not a simple concept and you need a data source that understands the complexity too.

The API is REST-based, returns JSON, and authenticates via the X-API-Key header. Holiday data is available on the free tier (60 requests/day). Business day calculations are a premium endpoint.

For business day calculations, you'll need a paid tier: Starter at $9/month (15,000 requests), Pro at $49/month (100,000 requests), or Growth at $149/month (500,000 requests). Annual billing saves about 25%.

Sign up at worlddataapi.com/dashboard to get an API key. Documentation is at worlddataapi.com/docs. We have guides for common financial use cases:

• Calculating Business Days in JavaScript

• Calculating Business Days in Python

• International Holiday Support