GithubHelp home page GithubHelp logo

mikepiper / open-social-security Goto Github PK

View Code? Open in Web Editor NEW
53.0 5.0 14.0 11.13 MB

Open-source calculator for determining best Social Security claiming age(s)

Home Page: https://opensocialsecurity.com/

License: MIT License

TypeScript 72.61% JavaScript 18.18% HTML 8.74% CSS 0.48%
social-security retirement financial-planning

open-social-security's Introduction

OpenSocialSecurity

This project was generated with Angular CLI version 1.7.4.

What Does This Calculator Do?

Firstly, please know that everything is done in "real" (i.e., inflation-adjusted) dollars. So there is no need for the user to make manual inflation adjustments.

Let's consider the simplest example: an unmarried person, using the calculator prior to age 62.

For such a person, the calculator:

  1. First assumes they file ASAP at 62.
  2. Calculates the amount of their monthly retirement benefit under such assumption.
  3. For each year up to age 115, the calculator multiplies the annual retirement benefit by the user's probability of being alive in such year, to arrive at a probability-weighted annual benefit.
  4. That probability-weighted benefit is then discounted back to age-62 value using the discount rate the user provided as input (i.e., to account for the fact that a dollar today can be invested and is therefore worth more than even an inflation-adjusted dollar in the future).
  5. All of those probability-weighted, discounted benefit amounts are summed, to arrive at a total "present value" for the assumed claiming strategy (e.g., claiming ASAP at 62).
  6. The above process is repeated for each possible claiming age (i.e., every month between 62 and 70).
  7. The claiming age that had the highest present value is then suggested to the user, and the present value associated with such claiming age is provided as well.

If the person is older than 62 when using the calculator, claiming strategies that are no longer possible (i.e., filing in the past) are eliminated from the analysis.

For a married couple, it's the same sort of process, but with more going on. Specifically:

  1. In addition to retirement benefits, spousal benefits and survivor benefits are included in the analysis.
  2. Probability weighting the various benefits each period involves separate calculations for "probability only Spouse A is alive", "probability only Spouse B is alive", and "probability both spouses are still alive."
  3. Each combination of possible claiming ages must be considered, for both spouses, and for both types of benefits (i.e., retirement and spousal).

When calculating monthly benefit amounts, as long as the user provides the necessary inputs, the calculator will account for an assortment of complicating factors, including:

  • Government Pension Offset (GPO) and Windfall Elimination Provision (WEP);
  • Child benefits for minor children or adult disabled children;
  • Disability benefits;
  • Child-in-care spousal benefits;
  • The fact that people born prior to January 2, 1954 have a different set of deemed filing rules than people born on or after that date;
  • Voluntary suspension;
  • Family maximum and combined family maximum rules;
  • The earnings test, for people who are younger than full retirement age and still working;
  • Retroactive applications.

open-social-security's People

Contributors

angular-cli avatar brian-courts avatar dependabot[bot] avatar kenyon avatar mikepiper avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

open-social-security's Issues

Inaccurate probabilityAlive calculations for some couples

When spouses are not the same age, the current probabilityAlive calculation can produce inaccurate results. If both spouses are under 62 and not disabled when beginning the calculations, each spouse's denominatorAge is taken as 62, and the base counts for mortality calculations are taken at that age. If they are born in 1958 and 1963, their base counts come from 2020 and 2025.

I do not believe an actuary would calculate joint probabilities for a couple taking data from different starting points. It can also create spurious results, such as a person's probabilityAlive calculated as greater than one and their probabilityDeceased less than zero, as shown in the attached spreadsheet. I have submitted a pullRequest with revisions to address this issue.

ProbabilityAliveCouple.pdf

Children-only benefits are not included in present value calculation for a couple

As currently written, the calculator does not include benefits that would be received by children after both parents are deceased.

In the "calculateCouplePV" routine in presentvalue.service.ts, starting at line 317, the probability-factored sum of benefits for a given year is calculated as follows:

//Apply probability alive to annual benefit amounts let annualPV:number = probabilityAalive * probabilityBalive * calcYear.annualBenefitBothAlive + probabilityAalive * (1 - probabilityBalive) * calcYear.annualBenefitOnlyPersonAalive + probabilityBalive * (1 - probabilityAalive) * calcYear.annualBenefitOnlyPersonBalive

        `//Discount that probability-weighted annual benefit amount to age 62`

The following line could be added to include benefits to children after both parents are deceased:

+ (1 - probabilityAalive) * (1 - probabilityBalive) * calcYear.annualBenefitBothDeceased

However, doing so would overestimate the benefits received by families with adult disabled children, because children are assumed to live forever.

URL query parameters missing child inputs

When child data is entered, it is not reflected in the URL so saving the link and re-using it doesn't work correctly.

The last query parameter defined in home.component.html is &&children={{qualifyingChildrenBoolean}}; looks to me like this needs to be updated to include parameters for the scenario.children array.

Incorrect rounding of benefits

To reproduce, use the default settings on opensocialsecurity.com:

Marital: Single
Gender: Male
DOB: 4 / 15 / 1960
PIA: 1000

The recommended strategy is to file on 4/2026, at age 66 and 0 months.

This then shows a table of Year-by-Year Benefit Amounts. The amounts in full years (after year 2026) are all shown as $11,200.

$11,200 per year would be a $933.33 monthly benefit. This is the 6.67% per year reduction from the $1,000 PIA.

However, I believe that the correct benefit is $933 per month or $11,196 per year, since the monthly benefit is rounded down.

With two recipients, each recipients benefit should independently be rounded down (I think). Though I'm not sure if for a recipient receiving both a personal and spousal benefit if each of those are rounded down before computing the full benefit, or if the rounding happens for the final benefit only.

This is largely splitting hairs. I don't mind if you close as will not fix.

I do note that selecting alternative claiming strategies at +/- 1 month from the suggested strategy produces results that are within a few dollars, so it is possible that a fix to this could produce a different claiming strategy in some cases. That said, the results of the different strategies barely disagree, so I'm not sure even this much matters.

Ability to explore survivor benefits

There doesn't appear to be an option to see what survivor/widow benefits would look like for different assumptions regarding the date of death of one spouse. For example, suppose both spouses have an FRA of 67. Suppose one plans to start SS at age 66 and the other at age 70. Spouse #1 is older than Spouse #1.
With the plan in place now, what does Spouse 1 benefits look like if spouse 2 dies at different ages?
There is an assumed age of death feature, but that feature reoptimizes. This request is assuming the optimization has already happened and decisions have been made. Now the user would like to see the effect of those decisions for different actual date of deaths. Assuming death occurs at the end of the year specified is fine.

Best regards

Survivor Benefits appear incorrectly calculated

To reproduce, I entered the following scenario into Open Social Security:

Marital Status: Widow(er)
Gender: Male
Date of Birth: 4 / 15 / 1960
PIA: 1000
Already filed for retirement benefits: no
Already filed for survivor benefits: no
Gender: Female
Date of Birth: 4 / 15 / 1960
Month/Year of death: 4 / 2020
PIA: 3000
Already filed for retirement benefits: no

The recommended strategy printed is:

You file for your survivor benefit to begin 2/2024, at age 63 and 10 months.
You file for your retirement benefit to begin 4/2030, at age 70 and 0 months.

2024	$0	$29,003	$29,003
2025	$0	$31,640	$31,640
2026	$0	$31,640	$31,640
2027	$0	$31,640	$31,640
2028	$0	$31,640	$31,640
2029	$0	$31,640	$31,640
2030	$11,160	$20,480	$31,640
2031+	$14,880	$16,760	$31,640

My understanding of survivor's benefit, possibly incorrect, is that for someone who:

  1. Dies before FRA (age 67 in the case of both of these people)
  2. And hadn't yet filed

Then the base survivor benefit will be the deceased's PIA ($3,000), and this will be adjusted proportionally between 71.5% and 100% of the survivor's age when they file for survivor's benefit, in proportion to how many months between age 62 and FRA (67).

In the suggested filing of age 63 and 10 months, the survivor is filing at 22 months after age 62 out of 12 * 5 = 60 months. 22 / 60 = 0.3666.

$3,000 * (71.5% + (29.5% * 0.3666)) = $2,145

Annually, that's $25,740, but your calculation shows a $31,640 benefit starting in 2025.

A $31,640 benefit would suggest opensocialsecurity is calculating a 12.1% reduction in benefits rather than the 18.7% reduction calculated above.


The math gets a little messy for the adjustment based on the survivor's filing date and I'm not sure I understand what I'm doing there correctly, so I tried something different. Using the same inputs as above, I then selected a alternative claiming strategy:

The survivor files for both retirement and survivor benefits on 4 / 2027.

This should be FRA for the survivor, and thus iiuc the survivor benefit should be exactly $3,000 / month, the deceased's PIA. Doing so, shows me an error:

Survivor benefits do not continue to grow as a result of waiting beyond your survivor FRA. Please choose a date that is no later than your survivor FRA (or no later than your earliest possible retroactive filing date, if you have already reached your survivor FRA).

This is confusing, as 4/2027 should be the survivor FRA.

I tried changing the values and the latest point where I don't get an error is 12/2026. I'm not sure why that might be the case. Is FRA being calculated as someone born in 1958 maybe, with a FRA at 66y 8mo?

Regardless, when I do so, I get the following text:

The present value of the strategy you selected is $405,562, as compared to a present value of $440,056 from the recommended strategy, a difference of -$34,494 (-7.8%).

2026	$978	$2,022	$3,000
2027	$11,733	$24,267	$36,000
2028	$11,733	$24,267	$36,000
2029	$11,733	$24,267	$36,000
2030	$11,733	$24,267	$36,000
2031+	$11,733	$24,267	$36,000

This doesn't seem correct because the survivor is filing at earlier than FRA, but it would be the correct survivor benefit if the FRA was indeed 12/2026. However, the personal benefit is indeed showing a reduction that looks correct for a 67y FRA.

Anyway, not sure exactly what's failing, but I thought I might share the debug case in case it's useful for testing. If I can provide more information, let me know.

Scale (or hide) range chart for mobile

relates to branch: component-for-range-of-options

Figuring out a way to scale the range chart for mobile would be good. Or maybe it would be easier/better to simply hide the component for mobile users. (Can mobile users even click on the table?)

Spousal Benefits are Calculated Incorrectly

A spouse cannot receive a 50% spousal benefit unless they start taking their own benefit at full retirement age. The calculator is quite misleading in this respect and indicates that the spouse's benefit jumps to 50% even if they start taking SS before their FRA.

Bug: range component output includes spousal filing date when not applicable

relates to branch: component-for-range-of-options

Relevant inputs:
personA born April 1951, PIA 2300
personB born April 1960, PIA 1000

Possible output when clicking on range chart:
NOTE: Spousal benefit may be claimed before retirement benefit.
Selected Option: Expected PV = $1,028,841, 99.6% of max. PV
Claim dates: You (retirement) 2/2021, Spouse (retirement) 11/2022, You (spousal) 11/2022,

In reality, there's no option for spousal benefits for personA. While personA has the old deemed filing rules, he/she is more than 8 years older than (nondisabled) personB, with a PIA of at least 50% of personB's PIA. So there's no way for personA to ever get spousal.

Also, "You (spousal)" shouldn't be in the output. (Lines 66 and 80 of claimDates.ts appear to be the issue here. But I haven't yet fully thought through the purpose of those lines, so I don't yet have a suggestion.)

And "Spouse (spousal)" should be in the output, but it isn't.

Convert range component output to unordered list and add ages

relates to branch: component-for-range-of-options

Maybe the "claim dates" part of the output would be a little more clear as an unordered list.

Also, I know from feedback I received on the original release of the calculator that people will want to see the age as well as the date.

Maybe something like this:


Selected option:

  • date1 (with age included)
  • date2 (with age included)
  • date3 (with age included)
  • PV
  • PV as percent of max

Error running presentvalue.service.spec.ts

Before making changes to files, when I ran
ng test
I got 1 FAILED, 168 SUCCESS
In presentvalue.service.spec.ts, approximate line 1924, gives error:

Tests for maximizeCouplePViterateOnePerson should tell a divorced user with lower PIA, two children already entitled on ex-spouse record, and an assumed age at death of 75 to file at 62 and 1 month for retirement and child-in-care spousal benefits FAILED
Expected $.year = 2020 to equal 2019.
Expected $.month = 0 to equal 11.
Error: Expected $.year = 2020 to equal 2019.
Expected $.month = 0 to equal 11.

Calculates unrealistic benefit totals for families with disabled adult children.

As shown in the attached spreadsheet, the online version of this calculator (which appears to be the same as the GitHub version) calculates unrealistic benefit totals for families with disabled adult children. There are two reasons for this:

  1. For married couples, the benefits that would be received by children if both parents are deceased are not added into the total. This results in totals that are 22% to 30% lower than they would be if the child-only benefits were included, in the disabled adult child cases I tested.
  2. For both single parents and couples, the calculator does not take into account the mortality of children. It assumes that children live until their parents reach the age of 115. That assumption results in totals that are 3% to 31% higher than they would be if it did take take into account the mortality of children, in the disabled adult child cases I tested.

The differences are much larger for disabled children than they would be for non-disabled children because non-disabled children only receive benefits until age 18, generally.

I suggest that the option to include disabled children be deleted and an explanatory note added, until the calculator can be revised to take into account children's mortality.

DisabledChildBenefits.xlsx

Incorrect Spousal benefit calculation?

(Following your article, I'll use Jane and Bob for examples, with Jane as the higher earner)

As I understand it, the Spousal Benefit is derived from the spouses PIA, and is NOT affected by the actual date that the spouse files for SS.

That is verified by your calculator so long as Jane files BEFORE Bob. But. I believe there is a bug in your code if Bob files for himself first.

The problem scenario is: Bob files first. Then at a later date, Jane files AND Bob files for spousal benefits at the same time. In that scenario, as I modify Jane's retirement date, leaving Bob's date constant, Bob's spousal benefit is changing! That is incorrect, right? Only Jane's PIA matters, not the age that she files.

I have been looking into this for hours, and the only explanation I can find is that the calculator is in error. If I am missing something, I apologize.

Regards,
Bill

Code Cleanup

I think we can do some code cleanup at this point. I'm happy to take it on (and I'll check carefully to see if anything causes problems, as I could be wrong about any of the below items). But I just wanted to check with you in advance in case there's something you have planned which would make this obviously inadvisable.

I think we can eliminate the cutString and cutOrNoCutString variables and related code. (Now tapping into the scenario object per my last commit.)

Ditto for selectedClaimDatesString and selectedPercentString.

Also ClaimDates.benefitDatesString().

Similarly, I'm looking into pvFractionArrays in range.ts, as well as related code. (Maybe not, as this is needed for the graph, not just the string output?)

bad assumption for someone born before 1954?

This issue is not necessarily a defect, as I suspect the calculator is working as designed, but I think the design is based on an incorrect assumption.

I'm the working spouse, 7 years younger than my non-working spouse (who has insufficient lifetime credits to collect her own benefit). Spouse default birth year when you load the page is 1960, and the answer to the question "Has your spouse already filed for retirement benefits?" defaults to "No". If I change spouse birth year to any year prior to 1954, the UI changes to a default answer of "Yes (spouse already filed)" and a date field appears. The radio button cannot be changed from "Yes" to "No", because I think you've made the assumption that anybody born before 1954 has surely already filed. However, my spouse, though 70 years of age, has NOT filed, because I've been employed, and I have not filed (age 63).

I may be wrong that you've made this assumption, but I definitely cannot change that radio button from "Yes spouse has already filed" to "No spouse has not filed". Thank you for the calculator.

Bug: range component output not responding to new clicks in already-filed scenario

relates to branch: component-for-range-of-options

Relevant inputs:
personA single, born April 1956, filed May 2018.

In the chart output, if you click around in the purple/pink area, it has no effect. It isn't changing the "selected option" output. It just leaves the results from whatever the most recently selected option was.

Miscalculates at 5/29 (60 yds 7 mo)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.