Supply chain, subcontractor, provider, and ultimate parent issues
Troubleshooting for supply-chain errors: wrong rank 1 provider, same-rank rows, recipient links, SaaS/PaaS/IaaS chains, ultimate parent repeats, and recipient-field rejections.
What this issue group covers
These issues usually come from a few recurring mix-ups: the wrong provider is being treated as rank 1, the recipient link points to the wrong provider, same-rank providers are being forced into one row, or parent-group structure is being mistaken for supply-chain order.
This page helps you place providers in the right part of the chain, report same-rank rows correctly, handle SaaS / PaaS / IaaS chains, and understand when a repeated provider code is expected.
Issues covered on this page
-
I do not know who the recipient of the subcontracted ICT service is
-
My recipient-of-subcontracted-services fields are being rejected
I am not sure where this subcontractor belongs
What this usually means
You are trying to place a provider in the ICT service supply chain, but it is not clear whether that provider is the direct ICT third-party service provider, a subcontractor, or a provider that should not be included in that chain.
What to check and how to fix it
Check whether this provider signed the contractual arrangement with the financial entity.
If it did, it is the direct ICT third-party service provider and belongs at rank 1, not as a subcontractor.
Check whether this provider signed with the direct provider or with another provider already in the chain.
If it did, it is a subcontractor and must sit at a rank higher than 1.
Check whether this provider effectively underpins the ICT service in scope.
If its disruption would not impair the security or continuity of the service, do not include it as a subcontractor unless the intra-group supply-chain rule applies.
Check whether part of the chain is intra-group.
If an intra-group provider sits between the financial entity and an extra-group provider, use Intra-group arrangements to link the intra-group arrangement to the extra-group arrangement before you finalise the supply chain.
Check that this provider is also recorded in Providers.
If it is missing there, add it first, then use the same identification code in ICT service supply chain.
Check that you are placing the provider by position in the service chain, not by ownership or group hierarchy.
Supply-chain position and parent-group structure are different things.
I do not know why this provider must be rank 1
What this usually means
You are assigning position by importance, ownership, or group role, when the rule is narrower: the provider closest to the financial entity in the contractual chain is always rank 1.
What to check and how to fix it
Check who signed the contractual arrangement reported in Contractual arrangements.
If that provider signed directly with the financial entity, it must be reported at rank 1.
Check whether you are treating an intra-group provider as something other than direct.
If the financial entity receives the ICT service from that intra-group provider under the reported arrangement, that provider is still rank 1 for that chain.
Check whether the provider only supplies another provider in the chain.
If it supplies the direct provider rather than the financial entity, it cannot be rank 1.
Check whether you are using group structure as a proxy for rank.
If you are, reset the ranking based on contractual proximity to the financial entity.
Check the rest of the chain after fixing rank 1.
Once rank 1 is correct, downstream subcontractors should follow at higher ranks.
I am not sure how to report multiple providers
What this usually means
More than one provider sits at the same position in the same ICT service supply chain, and you are unsure whether to force one provider above the other or combine them into one row.
What to check and how to fix it
Check whether the providers really sit at the same position in the same chain.
If they do, they should keep the same rank.
Check whether you are trying to put multiple valid values into one row.
If you are, split them into separate rows because each data element must contain a single value.
Check that the rows still belong to the same chain.
They should share the same contractual arrangement reference number and the same type of ICT services.
Check the recipient link for each row separately.
Same-rank providers still need their own row and their own correct linkage to the provider one level up in the chain.
Check the next level of the chain after those rows.
Do not force an artificial sequence between same-rank providers unless one actually subcontracts to another.
I do not know how to model this service chain
What this usually means
You are treating the direct provider’s service type and the subcontractors’ underlying technical layers as separate chains, when the chain should be built around the ICT service delivered to the financial entity and the subcontractors that underpin it.
What to check and how to fix it
Check which ICT service the direct provider is providing to the financial entity.
Start the chain from that direct service, not from the subcontractor’s technical layer.
Check whether the contract covers more than one ICT service type.
If it does, add separate rows for each relevant type instead of collapsing them into one row.
Check whether the subcontractors effectively underpin that direct service.
If they do, include them in the same chain even where they are technically providing a different layer such as PaaS or IaaS.
Check whether you are building the chain only from providers that share the same commercial label.
Do not do that. Build it from the contractual arrangement reference number, the ICT service in scope, and the subcontractors that underpin that service.
Check that the chain stays internally consistent.
One chain should keep the same contractual arrangement reference number and the same reported type of ICT services throughout.
This provider code is repeating
What this usually means
You have repeated the provider’s own identification code in the ultimate parent field and are assuming that this must be wrong.
What to check and how to fix it
Check whether the ICT third-party service provider is part of a group.
If it is not, repeating its own code as the ultimate parent code is correct.
Check whether the repeated code in Is this provider the ultimate parent company? matches the provider code already used in Provider ID code.
If it does, that is the expected result for a standalone provider.
Check the type-of-code field as well.
If the provider is not part of a group, the type of code should also repeat consistently.
Check whether you have left the ultimate parent fields empty instead.
If you have, replace the empty value with the provider’s own identification details before moving on.
Check whether the provider actually has a parent undertaking.
If it does, replace the repeated self-code with the true ultimate parent’s identification code and matching code type.
I do not know who the recipient of the subcontracted ICT service is
What this usually means
You are reading recipient as the financial entity or the business function. In ICT service supply chain, recipient means the provider one level up in the supply chain that receives the subcontracted service.
What to check and how to fix it
Check the field you are filling.
InICT service supply chain, Level of this provider in ICT supply chain, Subcontracted ICT service recipient’s ID code, and Subcontracted ICT service recipient’s ID type work together to link providers in the chain.
Check the reported level first.
If the provider is level 1, the recipient fields are not applicable under Annex I.
Check whether the provider is at level 2 or higher.
If it is, the recipient is the provider at level n-1 that subcontracted the ICT service to that row.
Check the recipient ID code against Providers.
If Subcontracted ICT service recipient’s ID code does not match that provider’s Providersidentification code, replace it.
Check the recipient ID type as well.
Subcontracted ICT service recipient’s ID type should match the code type recorded for that provider in Providers.
Related issues
My recipient-of-subcontracted-services fields are being rejected
What this usually means
The rejected row usually has a broken linkage in the supply chain. Most often, the recipient fields do not match the provider one level up in the same chain, or a level 1 row is running into the specific Subcontracted ICT service recipient’s ID code handling difference between the Annex I instruction and the reporting data-model workaround.
What to check and how to fix it
Check the rejected row against the provider one level up in the same chain.
If Subcontracted ICT service recipient’s ID code or Subcontracted ICT service recipient’s ID type does not exactly match that Providers record, correct those values and validate again.
Check whether the rejected row is actually a level 1 row.
If it is not, go back to the earlier sections on rank and recipient meaning, then correct the chain before validating again.
Check the base rule first for level 1.
Under Annex I, the recipient fields are not applicable for level 1.
Check whether the rejection is specifically tied to Subcontracted ICT service recipient’s ID code on a level 1 row.
If it is, use the practical FAQ-backed reporting workaround and fill Subcontracted ICT service recipient’s ID code with the same value as Subcontractor provider ID code, then validate again.
Check whether same-rank providers have been forced into one row.
If they have, split them into separate rows before re-running validation.
Related issues
What to do next
After you correct the chain, review Providers and ICT service supply chain together row by row. Check the provider identification code, level in the supply chain, recipient linkage, and ultimate parent details, then save and run validation again before export.