This topic follows my pull request on the SBTI-finance-tool Github repository. I was asked to ask my question here. You can find below my original message :
I noticed that the time frame parameter of a target is not constant over time : the time frame is set according to the value ‘end year of the target’ - ‘current year’. For example a target which starts in 2020 and ends in 2030 would have a MID time frame if we calculate its temperature score in 2022 (2030-2022=8), but in 2027 it would have a SHORT time frame (2030-2027=3).
I have 2 concerns about this :
- it does not make sense to have a non constant time frame : we use the annual reduction rate of targets to calculate the temperature scores from the regression models, suggesting that the reduction will be constant over the lifetime of targets. Let me illustrate : a target which lives from 2020 to 2050 will be mapped to a SHORT regression model in 2046. Therefore the tool will consider that the target is reducing its emissions at a constant rate for a maximum of 5 years, but it does not take into account that the constant reduction started 26 years ago.
- I am planning to compute everyday the temperature score of a portfolio and track the change over time. Each time the target of a company in my portfolio will change of time frame (between year 2025 and 2026 in my first example), it will be mapped to a different regression model, implying a suddenly non negligible difference of temperature score for no valid reason. I do not want this, and I think most of other asset management teams would agree with me.
I am suggesting either to replace the time frame value (line 249 of SBTI/target_validation.py, see image) by target.end_year - target.base_year (1), or to add a parameter year_time_frame in the calculate() method of the TemperatureScore class : this parameter can only take value ‘current’ (by default) or ‘start’, allowing users to choose which time frame mapping they want to use (‘current’ means the original SBTI time frame method will be used, ‘start’ meaning it will be the one I am suggesting in (1)) (2). This second option is what I implemented in this pull request. Please note that this branch can be used as the main one since if the parameter year_time_frame is not specified, the time frame calculation method will be the one already existing. Therefore users unaware of this code modification could use the tool as before