> ## Documentation Index
> Fetch the complete documentation index at: https://docs.myclerkbook.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Our privacy architecture

> Three independent layers, so privacy never rests on a policy statement alone.

The strongest privacy guarantee is the one you cannot switch off, and the
strongest of those is a capability that does not exist. myClerkBook is built
that way on purpose.

## The thing we will never build

**There is no bank connection.** No login, no aggregator, no read access to
any account you hold, on any plan, at any point.

<Note>
  This is architectural rather than a setting. There is no facility to connect
  a bank, so there is nothing to enable, nothing to misconfigure and nothing to
  breach. A product that never asked for your banking credentials cannot leak
  them.
</Note>

The line is drawn at the **credential**, not at the data. A statement you
export from your own bank and choose to upload is yours to give. Reading it
requires no login, no aggregator and no standing connection to anything. That
sits inside the principle rather than at its edge.

## Three layers

Privacy here is enforced in three independent layers, so that it never rests on
a policy statement alone.

<Steps>
  <Step title="Architecture: the capability does not exist">
    No bank integration, no aggregator relationship, no credential storage.
    The first layer is the one that cannot fail, because there is nothing there
    to fail.
  </Step>

  <Step title="The database: every row is scoped to its owner">
    Access rules are enforced by the database itself rather than by application
    code remembering to filter. A query that forgot a condition returns
    nothing, not somebody else's book.
  </Step>

  <Step title="Policy: what we commit to in writing">
    The [Privacy Policy](https://myclerkbook.com/legal/privacy) states what is
    collected, why, and for how long. It is the third layer because it is the
    weakest one: a promise is only as good as the two mechanisms under it.
  </Step>
</Steps>

## Document parsing

When document parsing ships, document content is stripped of identifying
information before it is sent anywhere for processing: names, email addresses
and account numbers are removed first, and what the model receives is amounts,
dates and descriptions without knowing whose they are.

<Warning>
  **No document is sent anywhere today, because parsing is not built yet.**
  That sentence describes the design of a capability that is specified and not
  running. When it ships, this page will describe it in the present tense.
</Warning>

## What this means in practice

<CardGroup cols={2}>
  <Card title="You choose what is recorded" icon="hand">
    Every entry is one you made or one you confirmed. Nothing arrives on its
    own from an account we can see.
  </Card>

  <Card title="No session recording" icon="video-slash">
    We do not record your screen or replay your sessions.
  </Card>

  <Card title="Your IP is not stored" icon="location-crosshairs">
    Product analytics runs without retaining it.
  </Card>

  <Card title="Deletion is real" icon="trash">
    No soft delete, no archived copy kept behind the scenes.
  </Card>
</CardGroup>

<Card title="Next: what we collect" icon="arrow-right" href="/privacy-and-security/what-we-collect">
  A plain-language inventory of every category of data.
</Card>