What it means

Your credentials authenticated successfully, but they do not match some aspect of the request payload. The upstream VOP provider accepted the TLS handshake and recognised the caller, then rejected the request because something inside the body — an identifier, a role, a permission scope — was not what it expected for that caller.

When you'll see it

• The X-Customer-ID you sent does not align with the identity of the certificate presented at TLS.
• Token claims on the upstream side (OAuth2 scope, issuer, audience) do not permit the operation encoded in the payload.
• The requesting BIC or LEI in the payload is not one you are authorised to verify against.
• A compliance or role-based restriction applies to this caller for this specific request shape.

Example response

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json
X-Request-ID: 550e8400-e29b-41d4-a716-446655440000
X-Rejected-By-Provider: true

{
  "type":    "https://errors.prod.prevop.alseda.eu/errors/client-inconsistent",
  "code":    "CLIENT_INCONSISTENT",
  "title":   "Credentials inconsistent with payload",
  "status":  400,
  "detail":  "Upstream rejected: caller not authorised for requestingAgent BIC"
}

How to fix

1. Make sure the X-Customer-ID you send matches the certificate the TLS handshake presented — they are linked on the alseda side.
2. Verify the payload's requestingAgent / partyAgent BICs are in your allowed-BIC list (visible in your alseda customer configuration).
3. If you recently extended your scope of service with alseda, the upstream provider may need to be notified — contact alseda to confirm the scope update has propagated.
4. Retry with a fresh X-Request-ID once the identity / scope mismatch is resolved.

Related

• Customer API Contract §4.2 — PreVOP error codes (CLIENT_INCONSISTENT row)
• See also: CLIENT_INVALID — credentials themselves were not accepted; this page is for when they were accepted but did not match the payload.