Compute day count to settlement

Give a trade date, a settlement lag and an ISDA day count convention. Get the settlement date on the Payments Canada calendar and the exact fraction. On this page it runs in this tab, and your inputs stay in it.

Input · request as JSON

Output · envelope

Input

One JSON object with seven named inputs, each given once, up to 4,096 bytes. It is the same body the endpoint takes.

input	what it is
`accrual_start`	The first day of the accrual period, written YYYY-MM-DD, such as 2026-07-01. Any year, on or before settlement.
`trade_date`	A business day on the calendar, written YYYY-MM-DD, such as 2026-10-09.
`settlement_lag`	Business days from trade to settlement, 0 to 5, as a string or a whole number.
`calendar`	`ca-payments-canada`, the one calendar this tool has.
`convention`	`ACT/360`, `ACT/365F`, `30/360`, `30E/360` or `ACT/ACT-ISDA`.
`acknowledge`	`no-ruling-v1`, exactly. This tool calculates. It does not issue rulings.
`freshness_tolerance`	How old the holiday calendar may be, in whole days written like `P7D`, no more than `P90D`.

Output

An envelope in JSON with these fields, in this order: tool, artifact_hash, status, refusal, result, inputs, provenance, ratified_ceiling, declared_tolerance, acknowledgment, disclaimer, attestation_badge, retention.

A computed call gives the settlement date, the day count, and the fraction in lowest terms with a decimal to 10 places, rounded half to even. A refused call gives a code and a message, and nothing was computed. artifact_hash names the artifact that answered, and provenance states the calendar and its age in whole days, or null when the clock reads earlier than the time the calendar was collected.

Settlement

Start at trade_date and move forward one business day at a time, settlement_lag times. A business day is a weekday that is not a system closure day on the calendar. A lag of 0 settles on the trade date.

Conventions

ISDA 2006 Definitions, Section 4.16. The period includes accrual_start and excludes the settlement date. A is the actual number of days between them.

ACT/360: days = A, fraction = A / 360.
ACT/365F: days = A, fraction = A / 365.
ACT/ACT-ISDA: days = A. Split the period by calendar year. The days in a leap year are divided by 366, the days in any other year by 365, and the parts are added.
30/360: start Y1-M1-D1, settlement Y2-M2-D2. If D1 is 31, D1 becomes 30. If D2 is 31 and D1 is now 30, D2 becomes 30. days = 360 × (Y2 - Y1) + 30 × (M2 - M1) + (D2 - D1), fraction = days / 360.
30E/360: the same, except a D2 of 31 always becomes 30.

The calendar

Payments Canada system closure schedule, from https://www.payments.ca/system-closure-schedule, collected at 2026-09-23T04:51:02Z. It covers 2026 only, because the source publishes the current year only. Saturdays, Sundays and the 10 closure days it lists are not business days. A trade date or settlement date outside 2026 is refused, never guessed. accrual_start may be any real date on or before settlement, in any year: no day count convention reads the calendar.

The calendar is bound into this artifact. Refreshing it is a new artifact and a new Clear by a person, never an update in place. Every answer states the calendar's age: whole days from the time it was collected to the clock this tool reads, or null when that clock reads earlier than that time. On this page that is this device's clock, so a wrong clock gives a wrong age and a wrong staleness check. The endpoint uses the server's clock. A call made while the clock reads earlier than the collection time computes nothing. The ceiling a person set for this tool is P90D. From 2026-12-23T04:51:02Z the calendar is 91 days old, so no call computes: one that passes the checks before the staleness check is refused as INPUT_STALE, until the calendar is collected again and a person Clears the new artifact.

Refusals

The checks run in a fixed order, listed in /hub.md, and the first that fails is the answer. On this page every refusal shows its code (listed in the table below), the field and rule it concerns, the message, and a valid example. The endpoint returns the code and a message that says what failed and, where a different request could succeed, what to send.

code	when
`INPUT_INVALID`	The request cannot be read or is over 4,096 bytes, an input is unknown, repeated, missing or not valid, the trade date is not a business day, or the accrual starts after settlement.
`ACK_MISSING`	`acknowledge` is not `no-ruling-v1`.
`TOLERANCE_MISSING`	`freshness_tolerance` is absent, null or empty.
`TOLERANCE_INVALID`	`freshness_tolerance` is not whole days written like `P7D`.
`TOLERANCE_OVER_CEILING`	The tolerance is above the ceiling a person set for this tool, or no ceiling is set yet.
`CLOCK_BEHIND`	The clock this tool read is earlier than the time the calendar was collected, even by 1 millisecond, so its age cannot be known.
`INPUT_STALE`	The calendar is older than the declared tolerance.
`OUT_OF_COVERAGE`	The trade date, the settlement date, or a business day walked between them falls outside the years the calendar covers. `accrual_start` is never refused for coverage.

The endpoint

The same core answers at https://foundry.dap.solutions/api/compute-day-count-to-settlement, by GET with query parameters or by POST with this JSON body: 200 when computed, 422 when refused. Prefer POST, because GET puts your inputs in the URL, where proxies and logs outside this tool may record them. A POST keeps them in the body. The description for agents is at /hub.md, and the hub is at /hub/.

Your inputs are not stored

On this page your inputs stay in this browser. The endpoint reads each request in memory and keeps no copy of your inputs. This tool sets no cookie and uses no browser storage.