mikepiper / open-social-security Goto Github PK
View Code? Open in Web Editor NEWOpen-source calculator for determining best Social Security claiming age(s)
Home Page: https://opensocialsecurity.com/
License: MIT License
Open-source calculator for determining best Social Security claiming age(s)
Home Page: https://opensocialsecurity.com/
License: MIT License
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.
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:
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.
How is the line "If your spouse outlives you" calculated?
In general, do you have links to the literature you used to construct the code?
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.
And if you wouldn't mind answering here which it is, I'd appreciate it.
The "Test an alternative claiming strategy:" near the bottom lets you test alternate claim dates. Entering claim dates up to six months in the past are rejected with error message [1] if the claim date is earlier than Full Retirement Age. However, I have a Saved Application on socialsecurity.gov with a start date less than six months ago BUT before my FRA. Once the Save Application is submitted, the start date on the app. is honored even if it's earlier than FRA. It would be nice if the optimizer would allow alternative claim dates up to six months ago regardless of FRA. If the date is before the FRA, the optimizer could warn "Retroactive applications are not allowed before FRA, but if you have a Saved App with this start date, that is okay."
[1] "The effective date for a retroactive application for retirement benefits must be no earlier than your full retirement age and no more than 6 months before today."
I've been running various alternate social security scenarios at the bottom of the page. At the moment, the calculator continues to solve for the spouse using its preferred start date (age 67) from the original calculation and not the inputted start date of 62.
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.
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.
Getting the javascript console error in title with regard to the following variables in range component:
minimumPvString
maximumPvString
minimumPvStringCut
maximumPvStringCut
Have never encountered this error before, so working on researching it now.
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?)
(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
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.
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.
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:
Wife was born 1964, husband was born 1969.
When entering info in the opensocialsecurity calculator, on top of page it works fine and gives suggested plan fine.
When entering info in the bottom of the page for ALTERNATE CLAIMING STRATEGY, I enter the following date:
Your month/year to claim retirement benefit: 5/2031
Your spouse's month/year to claim retirement benefit: 10/2026
Your spouse's month/year to claim spousal benefit: 6/2031
The error I get in pink background and red letters is the following:
Per new deemed filing rules, a person's spousal benefit date must be the later of their own retirement benefit date, or their spouse's retirement benefit date.
Both of these things are true so I don't understand why I'm getting this error.
relates to branch: component-for-range-of-options
When a user selects "yes" to a possible benefit cut, calculator fails to calculate results or provide a table for any alternative in the "alternative claiming strategies" section.
Spouses early benefit is not calculated correct. At least it does not match the Social Security page. Here are the numbers from the spouse (lower earner). Starting benefits for the spouse was suggested now (62 years and 11 months) but on the table of benefits a yearly benefit of $10,776 (which would be 898 per month. However the actual amount at 62 and 11 month from the social security page is 847. I have summarized this below and also added when the benefit would be 898.
YY.MM Monthly / Yearly amounts Comments
62.11 847 / 10,164 Actual amount now
63.7 898 / 10,776 Age when the benefit would be 898 / 10,776
67 1204 / 14,448 At full retirement age (67)
Mike
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
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.
When I get the “best option” takes survivor benefit at 5/2030 which is 60 yrs and 7 months, it is wrong in the survivor benefit.
if I change to one month later 6/2030, it reduces the survivor benefit by $500.
therefor the calculator is not useful for me. It’s great - but scared to use it really.
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.
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:
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.
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?)
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.