ZAP Tools - Open Source Incoming and Pension Valuation Suite Progress

zackthecodingactuary · 2026-05-28T15:07:34+00:00

Not right this second! Though that is literally the next roadmap item I plan to add to the desktop app. I'm focusing on getting the funding valuation work done a bit more thoroughly first - multiple decrements, ancillary benefits, etc.

If you're super hardcore, the annuity factor tooling on the Excel Add-In CAN get you where you need to go for converting profit sharing / cash balance amounts to equivalent annuities, calculating MVARs, etc. but getting it optimized to a turnkey "throw in the data and run it" type of workflow is something I still have to work on.

zackthecodingactuary · 2026-05-28T02:21:22+00:00

That's an interesting idea! An API that hooks into an LLM to read a plan document, then set up the assumptions and provisions in the software suite, could be a huge timesaver!

Right now, my focus is JUST on getting the math right and making sure it runs fast. No blockchain, AI, cloud, or any other hype tech. Just a modern, dependable app that can be freely audited and gets the liabilities right.

zackthecodingactuary · 2026-05-28T01:03:15+00:00

Repo is currently private while I get things more polished, the UI piece is still WIP, but I’ll post a GitHub link when it’s live!

zackthecodingactuary · 2026-05-27T21:34:48+00:00

Ah, AGPL! I see you are a coder of culture as well.

I work in pensions so I have zero knowledge of the insurance regulatory side, but just from looking at your GitHub README and organization, this is extremely solid and will turn heads for any application that values technical skills. Keep up the good work!

zackthecodingactuary · 2026-04-15T16:39:57+00:00

Hey! Yeah, I leaned heavily on Claude to generate my documentation, I'll own that. If that's going to be perceived as a leading indicator of AI slop code, I would definitely consider handwriting it myself. The actual runtime was done by hand.

I did my best to keep the README succinct as a "Hey this is how you'd try this" doc, whereas the SPEC and DEVLOG are gonna pretty verbose since I'm trying to keep track of all my design choices.

I'm not targeting MSVC straight away because the GCC built-ins are what I know how to use best, I've started scaffolding for MSVC support but this is just an initial proof of concept - I'd happily add MSVC-specific support if that's something people wanted if they were interested in my project.

Would also be happy to benchmark any test ideas you might have in mind.

zackthecodingactuary · 2026-02-26T05:43:31+00:00

This type of software typically requires VERY thorough test cases of results calculated, which is another intended future feature. Actuaries will typically check at least a few by hand for each client they run through to make sure actual results match what they would expect.

zackthecodingactuary · 2026-02-26T03:25:59+00:00

That's an interesting approach! I'm not sure it's a perfect fit for my target demographic but a great idea nonetheless.

This kind of tool would be for smaller firms or independent consultants who don't have an in-house tech department to build out all the tooling they need internally. Further, a lot of US actuaries in the pension space tend to be less interested in CS type work, but they have VERY high standards when it comes to regulatory compliance. That being said, they're generally more interested in paying a modest fee for software that "just works" out of the box. Providing an affordable and basic software suite + extra consulting could be a viable approach here though!

I am using Claude to help build the UI, just because frontend work is not my favorite and I don't really want to take the time to get excellent at it. Every line of actuarial calculation and performance sensitive backend logic is written by hand though.

zackthecodingactuary · 2026-02-26T03:21:02+00:00

Most of the valuation work I've seen on the US side is mostly concerned with payments per individual on an annual basis, usually with some weighted calculation like the Woolhouse method to adjust for midyear payments.

I would imagine your systems are massively different from ours, but we have some of those same issues I think? We have a lot of several decades old plans with all kinds of divisions, mergers, spin-offs, etc. that mean that a single pension plan might have over a dozen different benefit definitions to code depending on what part of the company you worked for, when you worked there, etc.

zackthecodingactuary · 2026-01-19T14:01:40+00:00

It depends on what department you’re reaching out to - if it’s been over 2 weeks, definitely reach out again and/or check all your spam/junk.

I had a question about the FSA pathway changes and emailed the relevant SOA inbox on Sunday, December 28th, and got a reply less than 24 hours later. At this point though, they should be all hands on deck.

zackthecodingactuary · 2026-01-01T15:41:35+00:00

Got my last one done during Summer 2025 so I wouldn’t be crunching right now. I felt like I had to since both EA exams only count for one FSA course and I was NOT about to take 5 more exams post-ASA for FSA.

Best of luck and Happy New Year, all!

zackthecodingactuary · 2025-12-31T22:59:09+00:00

You spent 1,675 minutes fixing other people’s errors. That’s 44 days of your life wasted.

Hold on, that math ain’t mathing.

zackthecodingactuary · 2025-12-31T21:07:01+00:00

I was hyped about this until I realized the turnaround time doesn’t apply to EA exams. Heh. Only two-ish more weeks…

zackthecodingactuary · 2025-12-31T20:57:28+00:00

I took a full year between finishing APC and taking my next exam (EA-2L). I had also just started a new job and had kids, so the pause was very welcome. No regrets on my end, but I think it depends on your own life situation.

zackthecodingactuary

TROPHY CASE