Privacy should be as precise as the record itself.

This interim policy applies to the Berlvis Spaces marketing site, controlled pilot application, and the property and tenancy operating records made available through Berlvis Spaces unless a later surface gives you a more specific notice.

BERLVIS SPACES LIMITED is the company responsible for the Berlvis Spaces service. We operate from Nigeria and can be contacted at support@berlvisspaces.com for privacy questions or requests.

Pilot and contact information: information you submit when applying for the pilot or contacting us, including your name, email address, phone number, city, the capacity in which you use property, approximate property or space count, how you currently operate, and the problem you want Berlvis Spaces to help with.

Account and relationship information: account identifiers, verified contact channels, and the relationships that connect a person to a property, space or tenancy, including owner, co-owner, tenant, manager or other permitted access context.

Property and tenancy information: property and space records, tenancy dates and terms, obligations, renewal points, documents, relationship history and other information needed to keep the property record coherent.

Payment and receipt information: payment amount, provider reference, confirmation state, payer and beneficiary context, allocation to obligations, coverage period and receipt evidence. Berlvis Spaces is designed to preserve confirmed financial facts rather than silently edit them later.

Identity-assurance information: verification status and method, a verified name where the architecture permits it, and protected match material used to reconnect a person to legitimate historical records. Sensitive identity evidence is handled separately from ordinary profile information.

Security, support and audit information: authentication and session events, permission and access changes, important actions, support records, failure information and other events needed to investigate incidents and reconstruct consequential activity.

Raw NIN is not stored at rest by Berlvis Spaces. Where an exact-match anchor is required, the architecture uses a versioned keyed HMAC so the database does not contain the original NIN or a simple reusable hash of it.

For the current v2 architecture, Berlvis may retain a verified name and its verification source. Berlvis does not persist verified gender, date of birth, address returned by the identity provider, provider reference portrait, facial image, liveness media or raw NIN as durable product data.

Identity-verification payloads are required to be redacted before general-purpose logging. Where an applicable erasure request reaches provider-held identity evidence, the architecture requires the erasure request to be propagated to the identity-verification provider as well as handled inside Berlvis.

We use information to create and operate property, space and tenancy records; establish the relationship and authority under which a person is acting; support payment and receipt workflows; maintain historical integrity; provide account recovery and support; protect the service; investigate misuse; meet operational or compliance requirements; and run the controlled pilot.

Identity assurance is not a blanket condition for ordinary use. The product architecture applies stronger identity checks to a narrow set of sensitive actions and historical-linking situations rather than treating verification as a universal role or plan requirement.

Pilot application information is used to assess pilot fit and contact you about that request. We do not use the pilot form as permission to add you to unrelated marketing lists.

Relevant people in the same property or tenancy relationship may see the information their relationship and permissions allow. One person's access to one property does not automatically give them access to another property.

Service providers may process information when they provide hosting, payment, identity-assurance, communication or other infrastructure functions. Berlvis is designed so no single provider becomes the source of product truth: provider confirmation or verification results are recorded through controlled server-side adapters.

Authorised Berlvis staff may access information only through the staff authority needed for support, operations, security, verification or other approved work. Customer property authority and staff platform authority are separate; staff access does not silently turn a staff member into an owner, manager or tenant.

We may disclose information where required by applicable law, lawful process, security response or a verified legal basis relevant to a property or account action.

Berlvis Spaces is built as a system of record. Confirmed financial facts, receipt evidence, material audit history and historical property or tenancy events are preserved so later changes do not rewrite what happened.

A profile change, new owner, new manager, later identity verification or later correction must not repaint an earlier confirmed payment or receipt. Corrections are represented as new attributable records where the architecture requires historical facts to remain immutable.

For this interim pilot, application and contact details are retained only for as long as reasonably needed to review the request, communicate with you and operate the pilot, subject to security, dispute, legal or record-keeping needs. This pilot-retention rule will be replaced by the formal retention schedule in the counsel-reviewed policy.

You may contact support@berlvisspaces.com to ask about access, correction, export, objection, restriction, deletion or other privacy rights that apply to your information.

The architecture distinguishes a person's current identifiable profile from historical financial and relationship evidence. On a valid erasure request, identifiable profile and contact information can be pseudonymised or redacted while the minimum financial, access and audit skeleton needed to preserve legitimate counterparty and system records remains intact.

Erasure therefore does not mean falsifying a landlord's, tenant's or property's historical payment and tenancy record. Where a record must remain, Berlvis should minimise the continuing identification attached to it rather than delete the event itself.

The architecture requires server-side permission checks, scoped and revocable access, audit history for consequential actions, masking of sensitive data where full values are unnecessary, signed access to high-sensitivity documents, rate limiting, backup and restore controls, and stronger step-up controls for privileged staff actions.

No online system can promise absolute security. Berlvis therefore avoids labels such as “unhackable”, “fraud proof” or “100% secure” and instead describes the specific identity, payment, property-review or permission state that was actually established.

This is a temporary launch policy derived from the current Berlvis Spaces architecture, not the final counsel-approved privacy notice. We will replace it when the formal legal and data-protection review is complete and will publish a new effective date when that happens.

If a change materially affects how pilot or product information is handled, we will update the public notice before relying on the changed practice where notice or consent is required.