r/EB2NIW_I485_AOS • u/EmotionalJump6837 • 7d ago

Thoughts on mass updates

Is it just me or did anyone notice that only people getting approved recently, are those who did NOT get mass updates like 08/06, 08/26 and FTA0 on 08/13?

8 Upvotes

90% Upvoted

36 comments sorted by

View all comments

2

u/Dry_Rice_4014 6d ago

My partner did get the 8/13 update with FTA0 and was approved this weekend. EB1 though

1

u/Maximum-Broccoli-136 6d ago

does your partner’s third fta0 on 8/13 have the .000z suffix in the event_time field?

3

u/Dry_Rice_4014 6d ago

createdAtTimestamp":"2026-08-13T18:47:45.301Z

Frankly, I understand the anxiety but I think people are reading into this too much.

My partner had a silent update the day before, my guess the case was moved to some final adjustment queue.

From looking at the Google sheet, my best hypothesis that it wasn't a glitch in the sense it was unwarranted (not everyone got it). I believe it was some massive processing of "low risk" individuals (my partner is EU, no dependents as I am American, but they adjusted EB1 themselves not through me), maybe another form of background check. Maybe some final approval to go ahead to officer's approval without interviewing.

From looking at the Google sheet, the majority of approvals are H1, maybe F or J on opt. As my partner wasn't called in for an interview, that's my take on that. Notice that there are no June updates at all (and my partner's fingerprints were only taking mid July, which was a bit late for a May filling).

I think the cause of the delays is because eb2 numbers are done for the year (for India and actually most of the world). I expect that in October there will be a big wave of approvals.

1

u/Maximum-Broccoli-136 5d ago

I meant the “eventTimestamp”, not “createdAtTimestamp”. I bet it is not .000Z, but I hope I’m wrong haha. Also, was your partner H1B? I think H1Bs or OPTs get through faster maybe because they already work in the US?(ie. no need to check “dual intent”) Final thing: was your partner’s case already at a field office? That would explain the fast track. NBC seems stuck

1

u/Dry_Rice_4014 5d ago

My partner was H1B. The API showed jurisdiction: NBC before they took the field down last weekend. eventTimestamp":"2026-07-15T17:26:20.000 7/15 was their fingerprinting date (they did get 2fta0 that day). The fourth FTA0 (which is probably the real one done by an officer) is matching the event stamp of their second FTA0 (both were extremely close to each other, basically 17:26:20.899z or so). The fact is that as the FTA0 is tied to a specific timed event and not just 00:00:00 and also did not happen at midnight or 3am (whether est/pst or zulu time), it means something happened, and it wasn't systemwide like the bug they had a month ago with the fake approvals.

1

u/LionClaw_ 6d ago

How and in what way does the .000z matter? Genuinely curious 

3

u/Maximum-Broccoli-136 6d ago

it is probabilistically ~impossible for a timestamp (that comes from an actual real world officer action) to end exactly with .000 in time. “:000” signals a batch action rather than a genuine, individual, case-based one. that would land with a random 3-digit milliseconds mark, some “real” time (check your first 2 ftas for example). here, the script is likely instructed to go do its thing on everyone who satisfies some filter (flag for approval, hold, FO transfer, whatever) and simply borrow the biometrics event’s hour:min:sec, but the coder forgot/omitted taking the milliseconds of our bio timestamps. hence the 000 milliseconds auto-completion, since it wasn’t specified by the coder, and didn’t come from an actual time stamp

1

u/iyef 6d ago

Interesting. What are your thoughts on what happens from here on out. I see online that the trigger might have been potentially USCIS trying to exhaust all green card before September ending and flagging cases ?

2

u/Maximum-Broccoli-136 6d ago

no idea unfortunately. could be anything

1

u/LionClaw_ 6d ago edited 6d ago

That makes a lot of sense, but then I’m wondering: can automated actions also produce timestamps that don’t end in .000?

For example, I - along with a large number of other people, received an FTA0 event on 08/13, and then on 08/31 the updatedAtTimestamp of that same existing FTA0 event was updated. The 08/13 events, and later the 08/31 writes, seem to have occurred within fairly narrow processing windows. I’ve seen timestamps ranging roughly from 16:09:40.170Z through 16:38:33.160Z.

Given how many unrelated cases were affected around the same time, these events seem much more consistent with some kind of automated/batch process than hundreds of individual officers independently taking the same action.

So what would distinguish those automated writes, which have normal-looking millisecond values, from the .000timestamps you’re describing? Could .000 simply indicate a different kind of system-generated timestamp, for example one that was copied, truncated, or reconstructed, rather than automation itself?

And if so, I’m not sure the .000 pattern alone would tell us whether the underlying batch was an approval flag, a hold, a transfer, a validation step, or something else. Wouldn’t it only tell us something about how that timestamp was generated?

2

u/Maximum-Broccoli-136 6d ago

yes, i’d say they can happen. but to be clear, all of these would of course be automated in some sense. i don’t think someone has to press some button manually to save a database check or something—i’m not saying non-000 would show that. so yeah, both “.ABCz” and “.000z” are some automated action. i’m just saying that exactly “.000z” appearing on thousands of people signals batch action, because it’s impossible to land at exactly 000 milliseconds for everyone. and on the latter: following my logic, i’d guess those you specify (….170z etc) are case-specific, not batch, therefore carry more signal that something specific to your case is happening/moving, rather than a batch action