Skip to main content

Known Addresses & IBAN Lookup

Backoffice view for cross-referencing any on-chain address or IBAN against everything the backoffice has ever recorded about it. Used by Customer Support, Compliance Officer, and Treasury Officer during process intake and review, and embedded as an inline check in every form that takes an address or IBAN.

The point is to surface conflicts — the same address tied to more than one IBAN or KYC reference, the same IBAN tied to more than one address or KYC — before a request moves forward.

Address Lookup (required)​

Paste or type an on-chain address (EVM or ZK). The backoffice assembles a detail view for that one address. There is no browseable list — the view is driven by the address the operator enters.

Detail view​

For the looked-up address:

  • Summary — total records, enforcement state (none, frozen, or oracle-sanctioned — live query, EVM only), and any active flags (see below)
  • Partner context — partner ID, date whitelisted, whitelist status (active / suspended), limits (if any)
  • Issuance requests — request ID, partner, status, amount, date
  • Redemption requests — request ID, status, IBAN, KYC reference, date
  • Enforcement records — request ID, action (freeze / unfreeze / seize), legal-ground tag, status, date
  • Observed incoming transfers — tx hash, amount, attribution (from the Incoming Transfers dashboard)

Flags​

Pinned at the top of the detail view:

  • Multiple IBANs — the address appears across redemption requests with more than one distinct IBAN.
  • Multiple KYC references — the address appears across redemption requests with more than one distinct KYC reference.
  • Active enforcement — address is currently frozen.
  • Oracle-sanctioned — Chainalysis sanctions oracle returns true for this address (EVM only, live query).
  • Whitelisted for a different partner — address is whitelisted for a partner other than the one on the request being reviewed.

IBAN Lookup (required)​

Paste or type an IBAN. The backoffice assembles a detail view for that one IBAN from every redemption request it appears in. No browseable list — same pattern as the address lookup.

Detail view​

For the looked-up IBAN:

  • Summary — total records, count of distinct source wallets the IBAN has been paired with, count of distinct KYC references, and any active flags (see below)
  • Redemption requests — request ID, status, source wallet address, KYC reference, amount, date
  • KYC references — every KYC reference the IBAN has been associated with, with the holder identity recorded on each

Flags​

Pinned at the top of the detail view:

  • Multiple addresses — the IBAN appears across redemption requests with more than one distinct source wallet address. Hard flag — review before approving.
  • Different KYC — the IBAN appears under more than one KYC reference.

Inline Check (embedded in processes) (required)​

Every backoffice form that takes an address or an IBAN renders an inline check next to the input. The check runs against the lookups above as soon as the value is entered and shows:

  • Summary line — "Known in N contexts" / "Not seen before"
  • Badges — partner, prior issuance, prior redemption, multiple IBANs, multiple KYC, frozen, oracle-sanctioned
  • Open details — opens the full Address Lookup (or IBAN Lookup) detail view in a side panel within the current process, without leaving the form

Flags do not itself block submission — they surface conflicts so the operator can decide. Process-specific gates still apply (e.g. issuance Step 1 rejects a destination that is not currently whitelisted, independent of the inline check).

Open Decisions​

DecisionSuggestedNotes
"Multiple KYC references" warningTBDDepending on what SumSub returns, that will have to be a manual check on SumSub side, to confirm all KYC references identify the same person