03Proof of Concept

What's Live

Every one of the following exists end to end today, not as a design mockup:

• Authentication, including registration, login, email verification, password reset, session management, optional two-factor email codes, and biometric unlock on supported devices.
• Identity verification, with both self-service submission and a staff review queue.
• Wallets, deposits, and withdrawals, covering both the member-facing flow and staff confirmation.
• Bank account management, with one-time-code verification and staff review of any change request.
• The marketplace and investment flow, covering scheduled resale windows, order placement, trade history, and capital commitments to new raises.
• Ownership and portfolio views, giving each member their own holdings and each asset a cap table.
• Revenue distributions, from staff-recorded income through dual approval to pro-rata payout.
• Governance, with proposals and unit-weighted voting.
• Documents and agreements, including uploads, versioning, and the legal agreements themselves.
• Staff and administrative tooling, covering member administration, platform configuration, an audit trail, analytics, and member communications.
• Self-service data rights, letting a member export or request deletion of their own data.
• Public contact and payment-provider integrations, including the site's contact form and bank webhook processing.

Security & Audit

Two facts anchor this section. First, the platform's financial ledger and every other legally significant record are immutable once written. They cannot be altered or deleted after the fact, a guarantee enforced at the database level rather than left to application discipline, so it holds even against someone with direct database access. Second, Signature's engineering team maintains a running, dated record of every security issue it has found and fixed through internal review, numbering more than eighty entries to date. A representative sample:

• Accounts are automatically locked out after repeated failed login attempts, separate from the platform's broader rate limiting.
• Login responses are deliberately shaped so that an attacker cannot tell, from response timing alone, whether a given email address has an account.
• Internal technical documentation is access-controlled and fails closed in production rather than defaulting to open.
• Startup checks reject weak or placeholder authentication secrets outright rather than allowing the system to run with them.
• The audit trail is written so that an action staff take on a member's behalf is never mistakenly attributed to the member themselves.

Beyond these: identity documents and bank account numbers are encrypted at rest using authenticated encryption with a unique key per value; permissions are enforced through a role-based access model on every request rather than scattered checks; every meaningful action across the platform lands in the same permanent audit trail; rate limiting is applied both by network address and by account; and a full set of security headers, including a strict content policy and forced encrypted connections, is verified automatically on every release.

Financial Controls

Every deposit, withdrawal, marketplace order, and revenue distribution is protected against being processed twice, even if a request is retried or submitted more than once by accident. Withdrawal confirmation uses a strict claim-and-lock mechanism: a request can only be picked up for processing by one process at a time, so a duplicate attempt is told the request is already being handled rather than being allowed to run again. When a payout's outcome is genuinely unclear after a network failure, the system checks with the payment provider directly rather than guessing, and if the answer is still ambiguous, the request is held for staff review. That is a deliberate choice to avoid both a false failure and a duplicate payment.

Deposit notifications from payment providers are verified twice before any wallet is credited: first by checking the notification's authenticity, then by independently confirming the transaction directly with the provider's own systems. The payload itself is never trusted on its own. A reconciliation process runs automatically at regular intervals, comparing the platform's internal ledger against the real balance held at the live payment provider, and only escalates a discrepancy to staff once it has persisted across several checks in a row, so ordinary settlement delay does not trigger false alarms.

Compliance & KYC

Identity verification only approves automatically when three independent conditions all hold: a verification provider is available, a real-time check against Nigeria's national identity database succeeds and that identity is not already claimed by another account, and the verified legal name plausibly matches the applicant's account name. If any one of those conditions fails, the submission is held for a staff reviewer rather than being auto-rejected. A member's self-declared status as a politically exposed person routes directly into a real staff compliance queue, not a form field nobody reads. A separate, ongoing monitoring process watches for deposit patterns commonly associated with structuring or money laundering and flags them for review.

Infrastructure & Uptime

The platform runs in a hardened production environment: a minimal-privilege container, a read-only filesystem, and a network configuration that exposes only what needs to be exposed. Two separate health checks exist for different purposes: one confirms the service is running, and the other confirms it can actually reach its database, so that a load balancer can redirect traffic away during a database outage rather than restarting an otherwise healthy service. Error monitoring is enabled deliberately, paired with an automated check that prevents secrets or personal data from ever reaching a log file.