Signature Private Cooperative
Investor Memorandum
A grounded account of what Signature has built, what has been verified, and what is still in progress. Every material claim in this document reflects the platform as it actually operates today, not a projection of where it is headed.
00Introduction
Signature Private Cooperative is the trading name of Signature Private Multipurpose Cooperative Society Limited, a Nigerian cooperative society (Registration No. ABSG/MOPASP/2026/00343) that pools member capital to acquire real estate, businesses, and agricultural assets, then divides each one into units members hold directly. This document exists to answer, plainly, the questions that actually decide whether a platform like this is real: does it work the way it says it does, does money move safely, is the legal structure sound, and where, honestly, does the platform still have work left to do.
Nothing in this document is a projection or a target return. It describes the system as it stands today.
01Executive Summary
The Problem
Real-asset investment in Nigeria sits at two extremes. Informal cooperative and contribution schemes move real money among real people but carry none of the operational rigor a member would want if their capital sat there for years: no audit trail, no independent valuation, no clear dispute process. At the other extreme, formally regulated investment schemes and REITs bring that rigor but are built for a different audience and a different minimum ticket size. They also structure the investor as a retail shareholder in an instrument, not as a member of a community they were personally vetted into.
Signature's own positioning names this gap directly. The platform is built to focus on real assets, not speculation, and on evidence rather than promises. Every asset carries an independent valuation and title documentation before it opens to members, and distributions are shown through a worked example rather than a projected return.
The Cooperative Model
Signature is not structured as a fund, a brokerage, or a registered investment scheme. It is a registered cooperative society under the Nigerian Co-operative Societies Act 98 of 2004, and its governing Membership Agreement is explicit about what that means for a member's position:
"Members explicitly acknowledge that they are not passive retail investors buying shares. Members are co-owners of cooperative capital units." Signature Membership Agreement
Capital contributions are tracked internally as cooperative asset units, not debt instruments, public equity, or deposit liabilities. What a member receives back is described as a patronage refund or surplus distribution, calculated from actual net performance rather than a guaranteed yield. The clearest statement of why this structure was chosen over a securities-style one appears in the agreement used for members who join without a personal referral:
"The Society is a Private Cooperative Multipurpose Society operating under applicable state and federal Cooperative Laws, and is NOT a public limited liability company, stockbroker, bank, or fund manager registered with the Securities and Exchange Commission or the Central Bank of Nigeria." Signature Walk-In Agreement
Why Now
The evidence gathered for this document reads as a platform past its initial build phase and into a hardening phase. Recent engineering work has concentrated on closing money-handling edge cases, encrypting sensitive member data at rest, and tightening error handling across the board, the signature of a team treating this as infrastructure meant to hold real capital, not a demonstration. Combined with a compliance and financial-controls layer that most platforms this size don't build until they are forced to, the case for admitting members now is that the underlying plumbing has already been built to the standard that will matter later, rather than one that needs to be retrofitted under pressure.
This is the one part of the document that is judgment rather than a checkable fact. Market sizing, timing, and competitive framing aren't things that can simply be verified against the product. If specific market-sizing figures are needed, they belong here as a separate addition.
02Proof of Concept
Five questions, answered from the platform as it actually runs: what exists end to end, how it is secured, how money is protected in motion, how identity is verified, and how the system stays up. For scale: the platform is covered by hundreds of automated tests that run against a real database on every change, and every proposed update is blocked from release if it introduces a known security vulnerability or leaks sensitive data into a log.
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.
"Live" here means the feature is fully built, tested, and in production use. It is evidence the system works as designed, not by itself evidence of transaction volume. That distinction matters and this document does not blur it.
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.
Dual approval on sensitive actions (described below) proves that two different staff accounts signed off. It cannot, on its own, prove that two different people did. One individual holding two staff-level accounts could in theory defeat that safeguard. The platform's own internal documentation says so directly rather than implying a stronger guarantee than actually exists.
This internal record of fixes is strong evidence of an active, ongoing security review discipline. It is not, on its own, a signed independent audit report. If Signature holds a third-party audit engagement separate from this internal process, it should be named and cited alongside this evidence.
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.
Which payment method actually processes a deposit or withdrawal (manual bank transfer or an automated payment provider) is a configuration decision staff can change, not a fixed architectural choice. Live automated payment processing is active today, which supports describing payment rails as genuinely live, but this is an operational fact worth reconfirming periodically rather than a permanent guarantee. A misconfigured environment falls back to manual processing automatically rather than failing.
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.
Government identity verification runs through a third-party provider's real-time lookup. The exact shape of every possible response from that provider has not yet been confirmed against live production traffic beyond the core match result. This should be confirmed before the integration is described elsewhere as fully verified end to end.
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.
Releasing a new version to production is a deliberate, manually triggered action, not something that happens automatically on every change. Every proposed change is still fully tested, linted, and security-scanned automatically before it can be released. Going live is a separate, controlled, human-triggered step that verifies the new version is healthy before switching traffic to it. That is a controlled-release posture, arguably a stronger trust story than fully automatic deployment, and this document describes it as what it actually is rather than as continuous deployment.
03Mathematical Modeling
The actual arithmetic the platform runs on, shown rather than only described.
Fractional Ownership Mechanics
Every asset carries a simple, enforced relationship between its total valuation and its units:
An asset moves through a strict sequence as it is prepared, listed, funded, and eventually closed, and the move from listed to funded happens automatically the instant a raise fills completely. Committing capital to a raise requires identity verification to already be approved, requires at least one full unit, and blocks the asset's own creator from investing in their own raise. Two protections are enforced at the strongest possible level, inside the database transaction itself, not only in the application layer sitting above it:
- Overselling a raise is structurally impossible. Two members committing capital at the same instant can never together commit more units than an asset actually has.
- A per-member ownership cap is checked both before a commitment is accepted and again inside the same transaction that finalizes it, closing a timing gap a simple check alone would leave open. Full consolidation of an asset by a single member through ordinary trading is, by design, unreachable.
A raise is strictly all or nothing. It only converts to member holdings once it is completely filled. There is no partial or minimum-viable-raise threshold today; an undersubscribed raise does not go forward at a reduced size, it is instead cancelled and every committed member is refunded in full.
Returns & Yield Distribution
Payouts to members use a method designed to divide money fairly down to the smallest unit of currency: each member first receives the whole-number floor of their proportional share, and any small remainder left over from that rounding is distributed one unit at a time to the members with the largest fractional claim to it. This guarantees the total actually paid out always matches the total available, never a fraction over or under. The amount actually available to distribute is calculated before that split happens:
Fee, VAT, and withholding-tax rates are configured by staff and capped so their combined total can never exceed the full amount. Distributions tied to the sale of an asset instead apply capital-gains treatment to each member's own individual profit, never a flat fee. Wallet crediting happens instantly, as part of the same transaction as the distribution itself, and above a configured amount, a distribution requires a second, different staff approval before it can happen at all, the same dual-approval principle used for withdrawals.
The homepage's own worked example, an asset earning a set amount in rent, a member holding five percent of the units, receiving five percent of that amount, illustrates a clean percentage of the gross figure. In reality, platform fee, VAT, and withholding tax are deducted from the gross amount before the pro-rata split happens, so a member's actual share is calculated against a smaller net pool. The existing disclaimer on that example covers performance variability but not this specific simplification. It is worth updating the marketing example to reflect the real arithmetic.
Describing a distribution as automatic refers to the crediting itself, which is instant once it happens, not to an automatic trigger the moment revenue is collected. Triggering a distribution is a deliberate action a staff member takes, and above a threshold, a second staff member must independently approve it first.
Risk Model
Assets carry real risk-disclosure information: a risk level, a plain-language summary of the main risk, valuation details including who performed it and when, and disclosure of any outstanding debt against the asset. Each of these defaults honestly to "not yet assessed" rather than silently defaulting to a reassuring value. The member-facing product reflects that honesty directly. When no risk summary has been published for an asset, it says so, rather than hiding the field or inventing a placeholder.
There is no mechanism today for writing down the value of an entire asset or issuing a negative distribution if an asset's value falls. The only loss concept that exists is a realized loss on an individual member's own secondary-market sale of units, where tax owed is floored at zero but the member's own profit figure can be negative. If a whole asset genuinely loses value, the platform does not yet have a built-in way to reflect that to holders. This is a real product limitation, not a documentation gap, and it is stated here as one.
Cooperative Pool Dynamics
Staff can cancel an entire raise at once, which automatically refunds every committed member in a single action. A member can independently cancel their own still-open commitment before a raise fills, though that option closes the moment it does. Secondary trading happens only inside staff-scheduled resale windows, never continuously. Placing a sell order immediately locks the underlying units so they cannot be sold twice, and a trade settles the buyer, the seller, the units, and the money together in one step or not at all. Three further safeguards exist, each staff-configurable: a holding period before newly acquired units can be resold, currently available but not turned on by default; a looser ownership cap that applies specifically to secondary-market trades; and a ceiling on how far above the raise price or last traded price a sell order can be listed.
The same dual-approval principle used for withdrawals is deliberately reused for revenue-entry approval rather than reinvented separately, a small but real signal that this was designed as one coherent system rather than patched together feature by feature.
04Legal & Governance
This section touches real legal exposure directly, so it stays strictly to what Signature's actual governing documents and systems say, and names plainly what would benefit from separate legal review rather than asserting it.
Cooperative Structure
Admission is by referral or Board sponsorship only, and the Board holds full discretion over acceptance. The agreement a member accepts is not a static document quietly baked into the product. It is generated and verified at the moment of acceptance, so what a member sees and what is recorded as accepted are provably the same text. A mandatory, asset-specific lock-up period applies to every contribution: early redemption or liquidation requests are not permitted, the legal counterpart to the marketplace's own configurable holding period.
A separate Walk-In Agreement governs applicants who join without a personal referrer. It grants only provisional candidate status, explicitly not automatic admission, and bars any financial transaction during that candidacy period until the Society's leadership formally sponsors the applicant.
Member Rights & Obligations
Beyond the transfer and lock-up terms above, the Membership Agreement includes broad indemnification of the Society, its trustees, and its developers, with a member's own liability capped at twelve months of their own admin fees paid. Disputes route through internal review first, then binding arbitration.
The strongest evidence of real member power sits in the governance system itself, not in legal language alone. A proposal to sell an asset must actually pass a quorum-and-majority vote, weighted by units held and locked in at the moment each vote is cast so a later trade cannot retroactively shift the outcome, before staff can even record the resulting proceeds. That is a structural gate on asset disposal, not an advisory poll members can be overruled on.
Regulatory Positioning
Signature's position is stated identically in its legal documents and on its public site:
"This platform is a proprietary administrative interface operating exclusively for registered members of Signature Private Multipurpose Cooperative Society Limited, registered under the Nigerian Co-operative Societies Act 98 of 2004 (Registration No. ABSG/MOPASP/2026/00343). We do not solicit funds from the general public, issue securities, or offer investment advisory services."
Nigeria's Data Protection Act is cited substantively in Signature's privacy policy, both as a retention-disclosure obligation and as the concrete set of rights it grants members: access, correction, deletion, objection, and portability of their own data. Those rights are not just stated; the self-service data export and deletion tools referenced earlier operationalize them directly.
No specific citation to Nigeria's Companies and Allied Matters Act appears anywhere in Signature's current legal documentation. If a claim specifically about that Act is ever needed, it requires separate legal sourcing; nothing in this review backs it, and nothing here should be read as implying it.
Asset Custody & Title
The trust structure is embedded in a real document every member can obtain, not just marketing language. Every Certificate of Unit Ownership a member can download carries a formal trust statement:
"The underlying asset is held in trust by Signature Private Multipurpose Cooperative Society Limited as trustee for the members who capitalized it, in proportion to their Cooperative Asset Units."
alongside an explicit disclaimer that the certificate is not itself a title deed. A member only ever receives an actual title-deed-class document if they consolidate one hundred percent of a single asset's units. For the platform's actual fractional product, this certificate and its trust statement is the only title-adjacent document any member ever receives, which matches what is stated publicly.
Internally, the system does not maintain a distinct legal-entity record representing the Society itself as titleholder in the way it maintains, say, a member record. In practice this is normal. Real trust structures are usually a paper and registry fact, not something every system needs a dedicated internal record for. But it is worth being precise: the trustee claim rests on consistent process and formally generated documents, not on a first-class internal record proving it on its own, and this document does not overstate that distinction either way.
The Society's registered address as stated in its own binding Membership Agreement differs by a single digit from the address shown publicly on the website and in the Society's contact information. One of the two is incorrect. This is exactly the kind of small, checkable inconsistency worth resolving before this document, or the underlying legal document, goes in front of anyone external.
The Membership Agreement describes unit transfers as approved individually by the Board, member to member only, with written notice and an administrative fee. The platform itself implements this as an automated, scheduled resale market open only to existing members instead. The underlying policy is the same in both cases (transfers stay inside the membership), but the exact mechanism described in the legal text and the mechanism actually running are not identical, and both should be described accurately going forward rather than treated as interchangeable.
05Roadmap
Current Status
Payment processing follows a deliberately conservative rollout. One automated payment provider is fully integrated and live today, including hosted checkout, dual-approval payout, notification verification, and live balance reconciliation. A second provider is built and ready but not yet the default. Manual, staff-confirmed bank transfer remains the safe fallback any misconfiguration lands on automatically. A genuinely sophisticated, staff-tunable operations layer is already live, not just planned: structuring-detection thresholds, dual-approval thresholds for both withdrawals and revenue entries, per-member ownership caps on both new raises and secondary trades, and separate tax withholding rates are all settings a staff member can change without any engineering work.
The shape of recent engineering work reads as a genuine post-launch hardening phase, not early build-out: closing money-handling edge cases in ownership limits and payout processing, encrypting sensitive data at rest, and tightening error handling across the board. What remains unfinished is tracked formally and deliberately rather than scattered informally, itself a signal of discipline worth noting.
What's Next
Taken directly from the team's own internal assessment of what is not yet built:
- Public technical documentation currently covers roughly a third of the platform's internal capabilities; the rest is not yet externally documented.
- The internal system that broadcasts events between different parts of the platform runs in a single process today; a more durable, distributed version is the planned upgrade once that guarantee needs to become absolute.
- Resale windows and governance proposals are opened and closed manually by staff today. The scheduling infrastructure for automatic, deadline-driven closing exists but is not yet connected.
- The holding-period safeguard on newly acquired units is built but ships turned off by default.
- Automatic refunding of a raise that times out unfilled needs a background scheduling capability and is explicitly deferred; a manual staff cancellation is today's workaround.
- A second automated payment provider beyond the two already covered has not yet been integrated.
This captures what the team's own internal assessment signals is unfinished. Any forward-looking business roadmap beyond this, new asset classes, timelines, or features not yet started, needs to come from the team directly and is not invented here.
06Marketing
Campaign Archive
No archive of past campaign material, advertising copy, or social content currently exists in a form this review could draw on. Real past campaign material, screenshots, links, and copy, belongs here once it is supplied.
Claims & Their Proof
Signature's own Trust page already states an editorial policy this document extends rather than invents: every claim it makes describes exactly how the platform is built, not aspirational policy, and if a control is not real yet, it is not listed. The table below applies that same policy as a checklist across every material public claim.
| Claim | Status | Basis |
|---|---|---|
| Every transaction sits on a permanent, tamper-evident ledger | Confirmed | Enforced at the database level, not just by convention |
| Overdrafts and oversubscription are structurally impossible | Confirmed | Enforced inside the transaction itself, not only checked beforehand |
| Funds only ever leave to the member's own verified identity | Confirmed | Withdrawal is gated on identity verification |
| Identity documents are encrypted at rest and masked everywhere shown | Confirmed | Authenticated encryption, verified in the platform's own security practices |
| Assets are held in trust, independently valued before allocation opens | Confirmed, with nuance | Real generated trust documentation; see Asset Custody above for the internal-recordkeeping nuance |
| The marketplace settles trades atomically, with funds held in escrow | Confirmed | Buyer, seller, units, and money settle together or not at all |
| A worked example showing five percent of a distribution reaching a member automatically | Confirmed, with nuance | Correct math, but omits real fee and tax withholding; see Returns & Yield above |
| Government identity verification through a third-party provider | Confirmed, with nuance | Real integration; full response handling not yet confirmed against live traffic |
| Not a public company, stockbroker, bank, or registered fund manager | Confirmed | Stated directly in the Society's own legal documents |
| Registered office address as shown publicly | Discrepancy found | Differs by one digit from the address in the Membership Agreement; see Asset Custody above |
| Whole-asset value can be written down if it underperforms | Not yet built | No mechanism exists today; see Risk Model above |
The published fee schedule
| Membership, custody, or investing | 0% |
| Exit profit fee | Percentage of profit only; a loss owes nothing |
| Marketplace transfer fee (seller-paid) | 1%, flat |
| Deposits (bank transfer) | Free |
| Withdrawals | Flat fee of ₦100 |
| Revenue distribution platform fee | 5%, withheld before the pro-rata split |
| Governance voting, statements, documents | Free |
07FAQ
Reproduced from the platform's own public FAQ, extended only where this deeper document answers something the public page does not need to.
Who can become a member?
Membership is by referral only, from an existing verified member or from staff directly. There is no public signup, and referring someone in earns no commission.
What's the minimum to start?
There is no fixed minimum. Unit prices vary by asset, and how much capital a member commits is simply however many units they choose above that per-unit price.
How does holding units actually work?
Two ways: revenue distribution when the asset earns, whether rent, business income, or a harvest, split pro-rata per the cooperative's bylaws, and resale gain or loss if a member sells their units during a scheduled resale window.
Can a member exit whenever they want?
No. Liquidity is deliberately bounded to scheduled resale windows rather than pretending a real, illiquid asset trades like a listed stock minute to minute.
Is a member's money safe while it sits in their wallet?
It sits on a permanent, audited ledger that reconciles exactly, and can only ever be withdrawn to the member's own verified bank account.
What happens if an allocation doesn't fill?
Every committed member is refunded automatically and in full. There is no minimum-raise threshold below which the platform proceeds anyway.
Do members get a say in the assets they own?
Yes, governance votes weighted by the units a member holds in that specific asset, and for a sale proposal specifically, that vote is a real gate: staff cannot record sale proceeds until it passes.
Who holds the actual asset?
Signature Private Multipurpose Cooperative Society Limited, as trustee for the members who capitalized it, not any individual member, and not the platform operator personally.
Does a member get a Certificate of Ownership or a Title Deed?
A member gets a personal Certificate of Unit Ownership recording their units, acquisition date, and cost basis. It is explicitly not a title deed. A literal title-deed-class document is only ever issued if a member consolidates one hundred percent of one asset's units.
08Glossary
Cooperative / Society
Signature Private Cooperative is the trading name of Signature Private Multipurpose Cooperative Society Limited, registered under the Nigerian Co-operative Societies Act 98 of 2004. A cooperative society, not a fund or a brokerage.
Unit
The fractional ownership instrument. An asset is divided into a fixed number of units at a fixed, platform-computed price.
Holding
One line of a member's portfolio, their position in one asset: units held, the current market-anchor price, and their own real weighted-average cost basis.
Raise
The fundraising and allocation period for one asset. Ends when the last unit is committed, all or nothing, or when staff cancel it and refund everyone.
Resale window
A staff-scheduled, time-bounded window during which members may list units for sale. Outside a window, there is no trading.
Pro-rata distribution
Revenue split proportionally to units held, net of platform fee, VAT, and withholding tax, using a method that guarantees the total paid always sums exactly.
Certificate of Unit Ownership
A personal record of units held, acquisition date, and cost basis in an asset. Not a title deed.
Trust / trustee
Signature holds legal title to each real asset as trustee for the members who capitalized it. A member's claim is a beneficial interest under that trust, not direct title.
Identity verification
Verification required before a member can contribute capital or withdraw. Deposits are allowed before approval; moving money out is not.
Politically exposed person
Self-declared at the time identity verification is submitted. Never automatically rejects a member; it gives staff something concrete to weigh at review.
Dual approval
Above a configurable amount, a second, different staff member must independently approve a withdrawal or revenue entry before it executes.
Walk-in candidate
An applicant admitted without a personal referrer, subject to a separate legal agreement and provisional status until formally sponsored by the Society's leadership.
09Contact
help@signatureprivatecoop.com · 0704 745 3529
No. 68 Macaulay by Ikot Ekpene Road, First Floor, Methodist Shopping Plaza, Umuahia North LGA, Abia State, Nigeria
Monday to Friday, 9:00 to 17:00 West Africa Time
See the address discrepancy noted under Asset Custody & Title before treating this address as final.