Contested Source Records
Efashe customer records claimed by two NEXUS parties
Two contested records, both waiting on an Efashe decision. A contested record is one Efashe customer id that two separate NEXUS parties both claim as their system of record link. Only one can hold it, and which one is a business decision rather than something the platform can work out on its own.
Contested now
2
Both queued
Raised in the last 30 days
7
5 already decided
Oldest open
4 days
C1 customer 884019
Decided by a rule
0
There is no rule to apply
| Efashe customer id | Claimant A | Claimant B | Raised | State |
|---|---|---|---|---|
| C1-884019 MSISDN +250 788 123 456 | PTY-0004471 Aline Uwase, Tier 2, active | PTY-0011908 A. UWASE, Tier 0, active | 15 July 2026, by the federation batch | Queued |
| C1-771204 National ID 1 1988 8 00214 55 3 | PTY-0008812 Jean Bosco Habimana, Tier 2, active | PTY-0012044 J B HABIMANA, Tier 1, dormant | 18 July 2026, by party federation | Queued |
How these arise. Federation resolves a NEXUS party to a C1 Efashe customer record on an identifier. When two parties resolve to the same customer, the second link is refused and the conflict is queued here rather than being overwritten, because overwriting would silently move somebody transaction history onto the wrong person.
Contested Source Records
Nothing is contested
No contested records
This is the normal state and it is stated rather than shown as a blank table, because a blank table looks like a query that failed. Federation ran 41,882 resolutions in the last 24 hours and none of them contested an existing link.
| Resolutions in the last 24 hours | 41,882 |
| Contested | 0 |
| Last contested record | 18 July 2026, decided 18 July |
| Average time to decide | 1.4 days |
| What would appear here | One Efashe customer id claimed by two NEXUS parties |
Zero is the number to expect. A steady trickle of contested records usually means duplicate parties are being created upstream, which is a registration problem rather than a federation one.
Contested Source Records
C1-884019, claimed by two parties
Neither side is presented as the likely winner. Both claimants are shown in full, in the same shape, because an operator who is shown a recommendation tends to accept it, and this decision has real consequences for whichever party loses the link.
Claimant A
PTY-0004471| Name on the party | Aline Uwase |
| National ID | 1 1993 8 00478 21 4 |
| MSISDN | +250 788 123 456, verified |
| Market | Rwanda |
| Lifecycle state | Active |
| KYC tier | Tier 2, verified 19 July 2026 |
| Created | 18 May 2025 |
| C1 link held | Yes, since 18 May 2025 |
| Wallet balance | RWF 184,250 |
| Transactions | 412 |
| Open loan | LN-2026-8814, RWF 85,400 |
Claimant B
PTY-0011908| Name on the party | A. UWASE |
| National ID | Not captured, Tier 0 |
| MSISDN | +250 788 123 456, verified |
| Market | Rwanda |
| Lifecycle state | Active |
| KYC tier | Tier 0 |
| Created | 15 July 2026, via USSD |
| C1 link held | None. This is the contest. |
| Wallet balance | RWF 2,400 |
| Transactions | 3 |
| Open loan | None |
The queued state, stated plainly. The link was not made. Claimant A holds the C1 link and claimant B has no system of record link at all, which is why B appears here rather than simply working. The screen says which one is unlinked rather than leaving an operator to infer it.
What this screen deliberately does not do. Nothing in the SOW or the decision register says who is entitled to keep a contested link. Rather than inventing a rule and applying it quietly, the platform surfaces the conflict and records whatever Efashe decides. If a rule is agreed later it can be added, and the decisions taken before it will still be readable.
Contested Source Records
What a decision here actually means
There is no rule to apply, and the screen will not pretend there is. Who is entitled to keep a contested C1 link is an Efashe business decision. No document states it, so the platform records a decision rather than deriving one.
| Possible basis for deciding | Argument for it | Why it is not a rule here |
|---|---|---|
| Oldest party wins | The link has been stable for over a year | It would freeze out a customer who has re-registered legitimately after losing access to an old handset |
| Highest KYC tier wins | Tier 2 is verified against NIDA, Tier 0 is not | It would let a verified impostor take a genuine customer history |
| Most activity wins | A has 412 transactions, B has 3 | It rewards volume rather than entitlement, and would be wrong in a stolen account case |
| Ask the customer | They know which account is theirs | Sound, but it needs a care process and an identity check that does not exist yet |
What is recorded either way. The decision, the operator who made it, the checker who confirmed it, the reason in their own words, and both parties as they stood at the time. If Efashe later agrees a rule, every decision taken before it can be reviewed against it.
Record a decision
There is no rule behind this, so the reason is the record. Write it properly.
A decision here is never applied by the maker. You record it and a second operator confirms it, because moving a customer entire transaction history from one party to another is not something one person should be able to do.
Contested Source Records
C1-884019 decision is with a checker
Nothing has moved. Claimant A still holds the link and claimant B is still unlinked, exactly as before. A contested record decision is only applied once a second operator confirms it.
| Contested record | C1-884019 |
| Decision recorded | PTY-0004471 keeps the C1 link |
| The other party | PTY-0011908 referred to care, left active and unlinked |
| Maker | j.mukama, today 16:52 |
| Reason | Same MSISDN, both verified. A holds a NIDA-verified Tier 2 identity and a year of history; B was created on USSD three days before the conflict. |
| Waiting on | Any operator with the identity approver role |
| In force meanwhile | The existing link, unchanged |
| If refused | The conflict returns to the queue with the checker reason attached |
| Step | Who | When | State |
|---|---|---|---|
| Conflict raised | The federation batch | 15 July 2026 | Done |
| Both sides reviewed | j.mukama | Today 16:44 | Done |
| Decision and reason recorded | j.mukama | Today 16:52 | Done |
| Checker confirms | An identity approver | Pending | Waiting |
| Link applied and both parties updated | The platform | After confirmation | Not yet |