# BRD-228 — Do not queue a second Authentication+ vet behind a pending one

> A second Authentication+ vet must not be submitted while one is pending.

- **Rule ID:** BRD-228
- **Layer:** Brand (`BRAND`)
- **Checks:** `the Authentication+ vet queue`
- **Severity:** MEDIUM — Usually survives review, but lowers your trust score or invites manual review.
- **When it bites:** Gates approval — get this wrong and registration is refused
- **How it is detected:** Deterministic (settled in code from the submitted values)
- **Fix type:** Fix the field — a better value in the form clears it
- **Required by:** TCR
- **Applies:** Applies when the brand is a public company.
- **Canonical URL:** https://ekas.io/rules/10dlc/brand/brd-228/

## Why this rule exists

The second order is refused rather than queued, so the natural response to a vet that seems stuck — order another one — costs a fee and achieves nothing. It seems stuck because the 2FA has not been answered yet, which is a different problem with a different fix.

## How to fix it

Check whether the 2FA mail has been answered before ordering anything. If the link has expired, re-request it (BRD-227); if the window has passed entirely, the existing vet has to fail before a new one can be placed. Done when only one Authentication+ vet is in flight.

## Example of a compliant value

```text
One Authentication+ vet in flight — chase the 2FA mail rather than placing a second order
```

## Provider rejection codes

| Provider | Code | Resubmission allowed |
| --- | --- | --- |
| TCR | `525` | yes |
