[Update] UTI 9% --> 10% = 9 point drop. But what is 10%?

[iv]

---

@Anonymous wrote:

Your reply, which is perfectly correct,  reminds me so much of a COBOL programmer I once worked with! That's a compliment, no matter what these Node.js and Python whippersnappers might say!

---

Heh.  I'll take it!

My first formal programming instruction (vs all the self-taught bits) was Scheme... followed by VAX assembly.  Gives an ...interesting perspective.

DIdn't end up as a programmer... sysadmin instead.  When I'm not wrangling bureaucrats, I make a bunch of other people's code play nice together in my sandboxes.

[iv]

---

@Anonymous wrote:

That's a really good point about that inquiry data. On January 23rd, I got a myFICO alert that my TU score went up +4 points. January 23, 2018 is the date of one of my inquires which shows at TU only. 

I know it's always possible that something else could have changed, but what a coincidence!

---

Yeah, the impact of inquiries dropping off at exactly 1 year to the day is, I believe, completely proven at this point.

You may not always see an impact from it (due to other activity on the reports, or due to having multiple inquiries - as there does appear to be a step function involved), but it always stops counting at exactly 1 year.  (Not sure about leap year effects, not that it matters much.)

[iv]

---

@Anonymous wrote:

---

Do we at least agree that 0, 10, 30, 50, 70, and 90 are the percentage thresholds that FICO is using internally for comparison, after any method of rounding?

---

With the caveat that I believe it's more like 0 < a < 9 < b < 29 < c < 49 < d < 69 < e < 89 < f straight thresholds vs any actual rounding?

Yes, those thresholds are reasonably well-established for overall utilization.

But...

Whether individual account utilization works exactly the same way?

Not sure.

Whether there are additional thresholds, especially in the 0-9 range?

Not sure, maybe?

I played around with that years ago, but before "number of accounts with balances" was known to have such an impact, so the data wasn't very good.

Whether certain FICO models use different utilization ranges?

Possibly.  Across multiple generations of FICO, and the industry options, it wouldn't surprise me.

How installment utilization is counted? (All installments together, or mortgages separated out, or scoring factors for both?)

Frequently debated...

How authorized user accounts affect any/all of the above, especially for FICO 8/9?

Good question, probably profile-specific.

[Anonymous]

---

@iv wrote:

---

@Anonymous wrote:

---

Do we at least agree that 0, 10, 30, 50, 70, and 90 are the percentage thresholds that FICO is using internally for comparison, after any method of rounding?

---

With the caveat that I believe it's more like 0 < a < 9 < b < 29 < c < 49 < d < 69 < e < 89 < f straight thresholds vs any actual rounding?

Yes, those thresholds are reasonably well-established for overall utilization.

I'm used to being given a set of thresholds to watch for in the software I write as part of data wrangling and real-time monitoring of thermal sensor data in large factory environments, so I'm coming at this from the perspective of dealing with two different data intervals. I'm guessing you are familiar with proportional integral derivative controllers (PID) and will understand how many times per hour sensor data can cross thresholds.

I kept seeing the advice to stay under 10% utilization so much, I just naturally established two sets of intervals in my mind. Either way works, but it's best for people to focus on the intervals you posted above.

The rest of your post addresses the real complexity of the FICO algorithm: all the weighting factors! 'Accounts with balances', 'Authorized User', etc. I know that in my own software the number of weighting factors is tremendous.

[Anonymous]

---

@iv wrote:

---

@Anonymous wrote:

Your reply, which is perfectly correct,  reminds me so much of a COBOL programmer I once worked with! That's a compliment, no matter what these Node.js and Python whippersnappers might say!

---

Heh.  I'll take it!

My first formal programming instruction (vs all the self-taught bits) was Scheme... followed by VAX assembly.  Gives an ...interesting perspective.

DIdn't end up as a programmer... sysadmin instead.  When I'm not wrangling bureaucrats, I make a bunch of other people's code play nice together in my sandboxes.

---

SERIOUSLY THOUGHT you were going to say IBM System/370 ! I love assembly - in moderation of course. lol

[SouthJamaica]

I'm loving this conversation @Anonymous and @iv 

Not understanding a word of it, but loving it nonetheless

[Anonymous]

In my experience there seems to be a threshold at four or five depending on how y’all want to round it. But I’m definitely enjoying following the thread as well.

[Anonymous]

---

@Anonymous wrote:
In my experience there seems to be a threshold at four or five depending on how y’all want to round it. But I’m definitely enjoying following the thread as well.

---

2 days ago I got a myFICO alert for an Experian score change that said, "The balance on one of your accounts has increased by $95."

699 -> 696, so -3 points.

[EDIT: Other changes to my report were only positive ones: good payment reported on one card, and overall ageing by 1 month. I have Experian CreditWorks Premium as well as myFICO 3B+ with the monthly report. ECP generates a new Experian report every single day, and there are no other changes between that -3 point drop report and the day before, besides the positive ones I mentioned. ]

Aggregate/total balance moved from 40/2000 to 135/2000, or 2% to 6.75%.

[SouthJamaica]

---

@Anonymous wrote:

---

@Anonymous wrote:
In my experience there seems to be a threshold at four or five depending on how y’all want to round it. But I’m definitely enjoying following the thread as well.

---

2 days ago I got a myFICO alert for an Experian score change that said, "The balance on one of your accounts has increased by $95."

699 -> 696, so -3 points.

It was moving from 40/2000 to 135/2000, or 2% to 6.75%. But then I wonder if the graphic below from a FICO whitepaper played a part (the highlighted section). My total balance did move from 1-99 to 100-499, after all.

---

No. The point loss was not causally related to the slight balance increase.

MyFICO alerts don't provide reasons for a score change. There are certain events which trigger MyFICO alerts.
If there happens to be any difference between your present score at that particular bureau and the previous score reported to you from that bureau, the score change is tacked on to the alert. There is not necessarily any connection at all between the score change and the alert substance. In your case I'm sure it was something else that caused the slight point loss.

[Anonymous]

---

@SouthJamaica wrote:

---

No. The point loss was not causally related to the slight balance increase.

MyFICO alerts don't provide reasons for a score change. There are certain events which trigger MyFICO alerts.
If there happens to be any difference between your present score at that particular bureau and the previous score reported to you from that bureau, the score change is tacked on to the alert. There is not necessarily any connection at all between the score change and the alert substance. In your case I'm sure it was something else that caused the slight point loss.

---

I wish they would stop providing the text along with the alerts. Also two other alerts changed the score factors listed under them as well - from not having 'too many accounts with balances' to adding it in later (at TU).

No wonder so many people are confused by it. I mean, what else is someone to think when they see those changes?

The reason that last update seemed so weird is that everything else that changed is normally a good thing: 1 month ageing, and one of my cards reporting a good payment.  The other card had no changes - the statement closing is today.

I'm convinced they just take a sample of moonlight brightness from a photocell between midnight and 3am and factor it in just to mess with us every now and then.