fintech-algorithms weekly downloads statistics

fintech-algorithms

**Corporate actions, index construction, market breadth, market microstructure, matching engines, execution algorithms and technical indicators — as plain TypeScript functions with zero dependencies.**

📖 Documentation → docs.thefintechbuilder.com — a reference page for every algorithm, with a worked example whose output was produced by running the code. Start with the quick start.

Split and dividend adjustment factors, capped free-float index weighting, McClellan breadth internals, dollar and imbalance bars, and the usual moving averages. Most npm packages in this space stop at indicators; the harder back-office arithmetic is the reason this one exists.

How the pieces fit together

Five things carry this library's name, and it is worth knowing which one answers which question before you go looking.

| | Answers | Updated by |

| npm | *Give me the function.* | A v* tag — CI publishes, never a laptop | | docs.thefintechbuilder.com | *What are the arguments, what comes back, is the arithmetic verified?* | Every push to main — no release needed | | thefintechbuilder.com | *What is this algorithm and why would I use it?* | The article, on its own schedule | | this repository | *How is it built, and how do I contribute?* | Pull requests — see CONTRIBUTING.md | | the agent skill | *Which import path and which field name?* | Ships inside the package |

Two of those links are worth spelling out, because they are the ones people assume and get wrong:

• A documentation URL and an import path are the same string. Swap https://docs.thefintechbuilder.com/ for fintech-algorithms/ and you have the import. That is enforced by a test, not a convention. • Docs do not wait for a release. The site builds from docs.json on main, so a corrected sentence ships immediately while the version on npm stays put. Check the two agree with version.json.

Writing this code with an agent? Install the skill first

**This is the single highest-value thing you can do before asking an agent to use this library.** Several hundred algorithms is more API than any model has read, and the failure mode is not refusal — it is a plausible import path, a plausible parameter and a plausible field name on the result, none of which exist. The skill replaces every one of those guesses with a lookup.

It ships in the Agent Skills format, so Claude Code, Codex, Cursor and some seventy other agents load it on demand. It carries the routing rules for every topic, the five input shapes with executed examples, the data-ingestion patterns for wiring up a provider, the failure modes that do not throw — the category that otherwise produces a confident wrong number — and a lookup script that answers from the installed docs.json, offline:

The skill is skills/fintech-algorithms/ here and also ships inside the npm tarball, version-matched to the docs.json beside it, so a project that already depends on the package already has it.

📘 The agent skill → docs.thefintechbuilder.com/guides/agent-skill/ · Background on how an agent should read this library: Using this library from an agent.

Adjust a price history for a 2-for-1 split

Pre-split prices are divided and volumes multiplied, so the series is continuous across the event and returns computed over it are correct.

Indicators work the same way — plain arrays in, plain arrays out:

null marks a warm-up observation where the indicator is not yet defined.

Bring your own data

The library ships no data provider. No Yahoo client, no exchange SDK, no node:fs, no network calls, zero runtime dependencies. Every algorithm takes plain arrays and plain objects, so the same code runs in Node, the browser, a Worker, Deno or Bun.

Adapting a provider is a short mapping function that *you* own:

When a vendor changes their API you edit one adapter; the algorithms never move.

Requires Node ≥ 22.12 — the require condition resolves to the same ES module, and require(esm) is unflagged from 22.12 onward.

Verified against published worked examples

503 of 597 topics have their arithmetic replayed and asserted on every build (145 via { input, expected }, 143 via a separate input and expected-output pair, 11 via row fixtures, 30 via bar/checkpoint fixtures).

Worth being precise about what that proves. The expected values come from the catalog, computed by a Python implementation written alongside the TypeScript rather than derived from it — so this is a cross-language parity check, not an independent third-party figure. It catches transcription and generation errors, which is the failure mode that has actually occurred here. It would not catch both implementations sharing a misreading of the source material.

The remaining 94 load and expose a callable entry point, but ship no machine-readable expected values, so nothing asserts their numbers. That gap is stated per topic rather than averaged away.

Every algorithm accompanies a published article that walks through a worked example by hand. Where that article ships machine-readable numbers, the test suite replays them and asserts the output matches exactly — so a green run means the package, the article and the standalone repo agree on the arithmetic.

It is an honest split, not a marketing number. Each algorithm's reference page states which tier it is in, and every worked example shown there is a fixture the test suite asserts — so those numbers cannot drift.

Import paths mirror article URLs

The subpath of every module is exactly the path of its article:

| | |

| Article | https://thefintechbuilder.com/technical-indicators/trend-smoothing/ema/ | | Import | fintech-algorithms/technical-indicators/trend-smoothing/ema |

One mental model for the site, the standalone repos and the package. It also means the 63 topics that each export a function named calculate never collide — they live in separate namespaces.

The five shapes

Every topic is an instance of one of five archetypes:

| Archetype | Signature | Count | Example |…

Description from the npm listing.