> ## Documentation Index
> Fetch the complete documentation index at: https://eurusys-6c0957fa.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Architecture

> How your application, the MBKYC SDK, and the Validation Gateway fit together — and how traffic reaches ICP.

The MBKYC SDK runs inside your application and handles two things for you: talking to local hardware (smart card readers and fingerprint sensors), and communicating with the Validation Gateway over a secure channel. You work with one simple API; the SDK takes care of the rest.

## The big picture

```mermaid theme={null}
flowchart LR
    subgraph Client["Your environment"]
        APP["Your application<br/>+ MBKYC SDK"]
        HW["Smart card reader /<br/>fingerprint sensor"]
        PROXY["Client proxy<br/>(entry point to ICP)"]
        APP --- HW
        APP --> PROXY
    end
    subgraph ICP["ICP"]
        VG["Validation Gateway"]
    end
    PROXY -->|"MPLS or IP-whitelisted channel"| VG
```

Your environment reaches ICP only through your own **proxy** — the agreed entry point between the two networks — over a private **MPLS** or **IP-whitelisted** channel. Nothing in your environment connects to ICP services directly.

## Domains go through your proxy

Your proxy fronts **every ICP domain** you use — the package repository, the dashboard, and the API. So each ICP hostname in these docs is really your **proxied equivalent**; your ICP contact gives you the actual hostnames. Throughout the docs we use these placeholders:

| What               | Placeholder       | Used for                                                             |
| ------------------ | ----------------- | -------------------------------------------------------------------- |
| Package repository | `repo.client.ae`  | Pulling SDK packages and desktop services from Nexus                 |
| Dashboard          | the Client Portal | Onboarding, API keys, devices, transactions                          |
| API                | `api.client.ae`   | The SDK's `baseUrl` — verification traffic to the Validation Gateway |

<Info>
  You configure the SDK with a single **base URL** — your proxied **API** host. The Validation Gateway is the boundary you integrate against: it receives your request, runs the verification against ICP records, and returns the result.
</Info>

## What the SDK does for you

<CardGroup cols={2}>
  <Card title="Talks to hardware" icon="usb">
    Discovers readers and sensors, reads the Emirates ID chip, and captures fingerprints — so you don't integrate vendor hardware yourself.
  </Card>

  <Card title="Secures the channel" icon="lock">
    Registers the device, opens an encrypted session, and submits each verification. You never build these requests by hand.
  </Card>
</CardGroup>

## Trust boundaries

<CardGroup cols={3}>
  <Card title="Your application" icon="mobile">
    Embeds the SDK. Holds the **non-secret** API key ID. Never holds the API secret.
  </Card>

  <Card title="Your backend" icon="server">
    Holds the API **secret** and signs requests on the SDK's behalf via the [token signer](/concepts/authentication).
  </Card>

  <Card title="Validation Gateway" icon="building-shield">
    Owns the verification decision and all identity data. Operated by ICP.
  </Card>
</CardGroup>

## On Android: hardware integrations

On Android, support for a hardware vendor can live **inside your own app** or in a **separate companion app** — whichever suits your deployment. Either way, the hardware integration must carry the **same Android signing certificate** as the SDK component that uses it, because that connection is protected at the signature level. The SDK then discovers the available readers and sensors automatically. See the [Android guide](/sdks/android) for details.

## The verification sequence

At runtime the SDK makes three calls to the Validation Gateway — register, handshake, validate — described in [SDK ↔ Validation Gateway](/concepts/backend-protocol).