Jump to content

Sign in to follow this  
ctb89

*BETA* Automatic INQ Counter for EQ and TU

Recommended Posts

ctb not sure if you saw this in the master thread, but these counted for me

 

FIRST ADVANTAGE CREDCO: 05/20/12 (1)

FIRST ADVANTAGE CREDCO/: 05/16/12 (1)

 

I am not sure why there is a forward slash on one of them. But it can definitely go on the white list.

Share this post


Link to post
Share on other sites

Can anyone tell me if a myfico pull for EQ is redundant with EQ Complete? I want to see if I can maximize my bumps this month...

Share this post


Link to post
Share on other sites

Can anyone tell me if a myfico pull for EQ is redundant with EQ Complete? I want to see if I can maximize my bumps this month...

It's expensive, but they're usually good for one soft a day.

Share this post


Link to post
Share on other sites

ctb not sure if you saw this in the master thread, but these counted for me

 

FIRST ADVANTAGE CREDCO: 05/20/12 (1)

FIRST ADVANTAGE CREDCO/: 05/16/12 (1)

 

I am not sure why there is a forward slash on one of them. But it can definitely go on the white list.

Those do count, but EQ doesn't even record them anymore (at least in my case). So it doesn't really matter... once the old ones are gone you'll probably never see another.

Share this post


Link to post
Share on other sites

I think I can confirm that in my case, the FAIR ISAAC's are being included in the EQ B* soft count. The counter showed my # of softs to be 76 including 3 FAIR ISAAC softs. I had 6 hards and I use three daily pullers (EQ C, USAA, & MPM). fusioncredit worked with me and predicted that if FAIR ISAAC's were included in softs, I should see 1 hard deleted the next day.

 

76 softs (including 3 FAIR ISAAC) + 6 hards = 82

82 + 3 daily pulls = 84 (magic number) + 1 hard deleted

 

As fusioncredit predicted, 1 hard from EQ was deleted after the daily pulls on the following day.

 

I know I'm a newbie and definitely green with B* so I may be missing something in helping confirm that the FAIR ISAAC softs can be included in the BETA EQ B* Counter but fusioncredit has been reviewing my B* progress over these past weeks and he was the one that predicted the correct # of hards to be deleted. So, this adds credibility to my observations.

 

Hope this helps in some way. I've been trying to absorb all the info on this site and have used the methods learned to successfully clean up my CR (still have some difficult ones that require continued dedication but I'm confident will get rid of) and have received so much help along the way from members on this site. I am just now feeling somewhat confident to give back a little from what I've received.

 

Thanks again for all the invaluable information and assistance from CB!

Edited by texastyke

Share this post


Link to post
Share on other sites

Thanks for taking the time to improve on my EQ counter and develop the TU counter. :) I was meaning to get around to it, but looks like I can take this off the 'some day' todo list. :)

Share this post


Link to post
Share on other sites

ctb89

 

if you can add this feature it would help. Can you give an option to enter a date to begin the count instead of counting all that appear?

 

btw I reference this thread (counter) in my spreadsheet tracker (see my signature)

Share this post


Link to post
Share on other sites

tried the the counter this is what i got

 

 

 

CIC/EXPERIAN ALRTS: 07/20/12, 07/19/12, 07/18/12, 07/17/12, 07/16/12, 07/15/12, 07/11/12, 07/07/12, 07/05/12, 07/03/12, 07/02/12, 06/30/12, 06/29/12, 06/26/12, 06/21/12, 06/09/12, 05/26/12, 05/23/12, 05/21/12, 04/26/12, 04/21/12, 03/30/12, 03/15/12, 02/23/12, 02/12/12, 02/07/12, 02/04/12, 01/17/12, 01/06/12, 12/31/11, 12/24/11, 12/22/11, 12/01/11, 11/28/11, 11/25/11, 11/22/11, 11/11/11, 11/10/11, 11/04/11, 10/30/11, 10/29/11, 10/25/11, 10/20/11, 09/26/11, 09/13/11, 09/07/11, 09/06/11, 09/03/11, 08/30/11, 08/29/11, 08/26/11, 08/25/11, 08/24/11, 08/13/11, 08/02/11, 07/31/11, 04/04/11, 03/28/11, 03/23/11, 02/16/11, 02/12/11, 01/29/11, 01/25/11, 01/06/11, 09/25/10, 08/06/10 (66) C* Detected!

 

Total confirmed softs found: 66

 

Total unconfirmed softs found: 0

 

Total possible softs found: 66

 

 

 

does this seems correct?

 

how many more do I need to see B or Im I gonna get C

it said at the end C" Detected

 

 

 

Thank you

 

 

 

Share this post


Link to post
Share on other sites

I have to say that this is totally fascinating and confusing at the same time. I have 8 hard pulls on TU. One is from 9/10...so that should be coming off in a few months. Then there are 4 from purchasing one car(3 from the same comany(Kia) and one from a credit union that we were considering using) from 7/11. One from the student loan I got for my son 8/11 and 2 from the car I purchased for him 10/11. So 7 of them are a year or less old and the one should be close to dropping off. Should I wait to bump until after the 9/10 disappears? Also, do I have a legit disput to get the Kia pulls off? Two seem to be from KIA headquarters and one from the dealer. Thanks for any advice!!

Share this post


Link to post
Share on other sites

in a nutshell

 

you basically have to get 84 softs created AFTER your last hard you are trying to get rid of. This is for Equifax. For Transunion the magic # is 56.

 

For EQ you must get to this # in 28-35 days immediately following the last monthly chop which just happened (July 15-20) before all your softs get wiped again.

 

TU has no chop so no rush.

 

Some hards are "stickie" and will never drop off with this method. This method does not work on Experian

 

Get busy pulling! You only have until Aug19-24 to get your 84 in or else you're wasting your time. Do the math. Download my spreadsheet.

Edited by junkyour925

Share this post


Link to post
Share on other sites

I'm seeing a couple people in this thread reference the magic number for EQ as 84. I haven't been very active lately but last I checked it was 85.

Share this post


Link to post
Share on other sites

in a nutshell

 

you basically have to get 84 softs created AFTER your last hard you are trying to get rid of. This is for Equifax. For Transunion the magic # is 56.

 

For EQ you must get to this # in 28-35 days immediately following the last monthly chop which just happened (July 15-20) before all your softs get wiped again.

 

TU has no chop so no rush.

 

Some hards are "stickie" and will never drop off with this method. This method does not work on Experian

 

Get busy pulling! You only have until Aug19-24 to get your 84 in or else you're wasting your time. Do the math. Download my spreadsheet.

 

Thanks! I love your spreadsheet. For TU I pulled all three (CK, SC and TU) today. But you say that there is no chop for TU, right? So can you do more than one a day on them or is that fruitless?

 

 

For EQ I signed up for MPM and EQ. It looks like your have to have an AMEX card to join that. For USAA do you start with the "FREE FINANCIAL ASSESSMENT?"

 

Thanks again!!

Share this post


Link to post
Share on other sites

Thanks! I love your spreadsheet. For TU I pulled all three (CK, SC and TU) today. But you say that there is no chop for TU, right? So can you do more than one a day on them or is that fruitless?

 

 

For EQ I signed up for MPM and EQ. It looks like your have to have an AMEX card to join that. For USAA do you start with the "FREE FINANCIAL ASSESSMENT?"

 

Thanks again!!

 

bjs123,

 

You should be able to join USAA by starting here... USAA Membership

 

 

Just choose the option that you are not a current member, and it will walk you through the steps. I was able to join with no issues. Good luck!

Share this post


Link to post
Share on other sites

Hmm this thread is fairly quiet...I assume everything has been working fairly well?

Share this post


Link to post
Share on other sites

Hmm this thread is fairly quiet...I assume everything has been working fairly well?

 

summer doldrums? I guess everyone is busy bumping away...I have been. All C* B* threads are dead

Edited by junkyour925

Share this post


Link to post
Share on other sites

You know...I have been thinking ( I know I know dangerous) there must be a wy to bump EX. The reason EQ and TU bump is that their record size for something in their database has been maxed or the data structure (stored procedure) they use to return a record set or hold/load a value into memory for display or transmission has been maxed. EX does not have unlimited data storage and their software for displaying or transmitting is not unlimited either. So when a third party requests a creit report the transmission packets are not unlimited...everything is of a certain size...maybe we just do not know why the max is EX yet before B*. Anyone have ny outrageous soft counts on EX to reference? Wonder hat the data format is between EX and requesters? Sorry about the typos....just thinking out loud on an iPad....

Share this post


Link to post
Share on other sites

It's been tried multiple times in the past.

 

Never ends well, and messes things up for everybody else.

 

Let it go. ;)

Share this post


Link to post
Share on other sites
1344307359[/url]' post='4728824']

It's been tried multiple times in the past.

 

Never ends well, and messes things up for everybody else.

 

Let it go. ;)

 

Yeah...I hear ya....pretty sure I could crack this nut (programming interface docs are all over the web...not to hack their system or anything but just to see how the data is structured to determine bumpsblity)..,but I can see how this could cause issue so for the greater good I will not open pandoras box....consider this a dead idea. In fact...maybe we should just delete my earlier post... Bob can you get a mod to tke it down? I don't want anyone getting a bad or the wrong idea...

Share this post


Link to post
Share on other sites

It's OK, the last attempt set off so many alarms that further attempts are probably futile.

Share this post


Link to post
Share on other sites

Hmm this thread is fairly quiet...I assume everything has been working fairly well?

 

summer doldrums? I guess everyone is busy bumping away...I have been. All C* B* threads are dead

 

No doldrums here - I've been B* away! And, I've had great results. Crossing fingers here, but I started with 15 hard inquiries on 7/20, and that's when I started daily pulls with USAA CCMP, Amex CS, and EC. I also added MPM a couple of days later. I am currently down to 3 HP, and if all goes well they should drop off tomorrow.

 

I'm also pulling SC daily, but I've only got about 10 of those softs so far - may buy a TU report just to see where I am in the grand scheme of things. I've got 6 HP there, and can't wait until they all drop off, too.

 

This has been a great find - love the info available on here! :)

Edited by VolFan

Share this post


Link to post
Share on other sites

sweet! Good for you bro!

 

I just had my first ever TU bump today....oh what a great feeling to be in charge of the petty functionaries. lol

 

EQ bump should be happening any day now!

Share this post


Link to post
Share on other sites

Hmm this thread is fairly quiet...I assume everything has been working fairly well?

 

summer doldrums? I guess everyone is busy bumping away...I have been. All C* B* threads are dead

 

Yeah probably. I started work 6 weeks ago and have been pretty busy. I'm getting settled now though so will have more time to spend here.

Share this post


Link to post
Share on other sites

You know...I have been thinking ( I know I know dangerous) there must be a wy to bump EX. The reason EQ and TU bump is that their record size for something in their database has been maxed or the data structure (stored procedure) they use to return a record set or hold/load a value into memory for display or transmission has been maxed. EX does not have unlimited data storage and their software for displaying or transmitting is not unlimited either. So when a third party requests a creit report the transmission packets are not unlimited...everything is of a certain size...maybe we just do not know why the max is EX yet before B*. Anyone have ny outrageous soft counts on EX to reference? Wonder hat the data format is between EX and requesters? Sorry about the typos....just thinking out loud on an iPad....

 

Why do you think there must be a way? The limits that EQ/TU are bumping up against are certainly not storage or bandwidth related. They are definitely legacy software based limits (think Y2K type issues). Maybe they are using ints instead of bigints, etc. There are a million reasons. Memory has nothing to do because only indexed data will be in RAM (if it's indexed at all which is unlikely) and transmitting it to a third party will just read parts into RAM before sending to TCP/IP stack and then to NIC. The textual data of a credit report is so tiny compared to modern servers (think of serializing the array/object containing all the data...it's still going to be relatively small). You are right in that they don't truly have unlimited capacity, but for all intents and purposes, they do. Certainly from the perspective of one individual they do.

 

Facebook stores many orders of magnitude more data points than do credit agencies, and they have no problem storing, retrieving and transmitting that under much heavier work loads to a much larger audience.

Share this post


Link to post
Share on other sites

You know...I have been thinking ( I know I know dangerous) there must be a wy to bump EX. The reason EQ and TU bump is that their record size for something in their database has been maxed or the data structure (stored procedure) they use to return a record set or hold/load a value into memory for display or transmission has been maxed. EX does not have unlimited data storage and their software for displaying or transmitting is not unlimited either. So when a third party requests a creit report the transmission packets are not unlimited...everything is of a certain size...maybe we just do not know why the max is EX yet before B*. Anyone have ny outrageous soft counts on EX to reference? Wonder hat the data format is between EX and requesters? Sorry about the typos....just thinking out loud on an iPad....

 

Why do you think there must be a way? The limits that EQ/TU are bumping up against are certainly not storage or bandwidth related. They are definitely legacy software based limits (think Y2K type issues). Maybe they are using ints instead of bigints, etc. There are a million reasons. Memory has nothing to do because only indexed data will be in RAM (if it's indexed at all which is unlikely) and transmitting it to a third party will just read parts into RAM before sending to TCP/IP stack and then to NIC. The textual data of a credit report is so tiny compared to modern servers (think of serializing the array/object containing all the data...it's still going to be relatively small). You are right in that they don't truly have unlimited capacity, but for all intents and purposes, they do. Certainly from the perspective of one individual they do.

 

Facebook stores many orders of magnitude more data points than do credit agencies, and they have no problem storing, retrieving and transmitting that under much heavier work loads to a much larger audience.

 

I have no idea what any of that means tongue.gif

Share this post


Link to post
Share on other sites

Agree ctb the limits could be related to a data construct that is passed via their API. And no there is no guarantee the size constraints are the issue. I would suspect that with EQ and TU the bumps are due to either an internal system construct being maxed out (like an array or something that is bound...or a queue) thus the FIFO ordering...or less likely...there is a record constraint on their database that forces a deletion to add a new record at a certain size point. It is possible that if it is a construct related to their API for passing data to outside parties(like a mortgage broker) that their internal systems still contain all of the bumped inqs....though I suspect they would clean them out... I was a lead architect for fortune 100 company for many years before I succumbed to the dark side (mgmt) and we killed all data of this sort...it was deemed safer to delete it so that it could not be used against us in court...any way...going to take bobs advice and let this die..,, :)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  




About Us

Since 2003, creditboards.com has helped thousands of people repair their credit, force abusive collection agents to follow the law, ensure proper reporting by credit reporting agencies, and provided financial education to help avoid the pitfalls that can lead to negative tradelines.
×
×
  • Create New...

Important Information

Guidelines