Actor(s): Buyer, Compliance Team, System, Keycloak

Goal:
Ensure compliance by verifying the Buyer’s identity, conducting fraud checks, and determining their relationship with our Platform. The Buyer is either onboarded or rejected.

Preconditions:

• UC 32-1 Support for Individual Buyer onboarding
• UC 32-2 Support for Company Buyer onboarding
• The Buyer has submitted an onboarding application with initial data.
• Compliance checks (KYC/KYB/AML/Fraud) will be done manually.
• The system creates a ticket in Odoo for manual Buyer review (approval or rejection).

Postconditions:

• Approved Buyer gains access and a Wallet is created (MVP2 - based on additional information collected).
• Rejected Buyers are blocked.
• Compliance records are logged manually (MVP1 - for all buyers, MVP2 - for buyers who haven’t passed the automated KYC-KYB process).
• UC 42-2 Manual Buyer account updating triggered if necessary.

Main Flow:

1. The system adds a ticket to Odoo for manual review by the BM.
2. MVP1: BM reviews manually (identity, business legitimacy, fraud risk, etc.)
3. MVP2: The system determines flags based on automated KYC processes.
4. The BM collects information from external resources, e.g., googling.
5. If required, BM requests additional documents from the Buyer.
6. If all checks are passed, the Buyer is approved, and their Wallet is created.
7. If concerns persist, the Buyer is rejected.
8. BM logs compliance records manually.

Tasks for BM in Odoo:

1. Edit user profile (incl. unflag the User).
2. Seek additional data from external sources including googling for cross-checking KYC/KYB/AML compliance.
3. Add additional data about the User to BO based on flags or manual onboarding.
4. Upload documents to BO.
5. Accept or reject the buyer.
6. Alternatively, request additional information from the buyer.
7. MVP2: View the provided data in Sumsub.
8. MVP2: Generate and send a new Sumsub verification link to the Buyer if needed.

---

Actor(s): Buyer, System, Keycloak,** MVP2: External KYC/KYB Provider**

Goal:
Enable Back Office Managers to update the Buyer’s account information and ensure compliance with updated KYC/KYB/AML requirements. The Buyer’s profile is manually updated by BM based on the information provided by the Buyer.

Preconditions:

• UC 32-1 Support for Individual Buyer onboarding
• UC 32-2 Support for Company Buyer onboarding
• Alternatively, UC 42-1 Buyer’s KYC/KYB/AML/Fraud Prevention Checks and Relationship Determination with requests for additional information for higher-risk Buyers and/or incomplete data for compliance.

Postconditions:

• The Buyer’s updated information is verified, approved, and saved, or rejected if non-compliant.
• The Buyer’s transactions are blocked if the updated information does not meet KYC/KYB/AML requirements.
• If previously blocked for non-compliance, the Buyer’s transactions may be unblocked if the updated information now meets requirements.

Main Flow:

1. The system creates a ticket for BM, indicating Buyer updates information and/or adds documents subject to manual control in Self-Service (MVP2), or responds with requested info/documents.
2. BM verifies and validates the submitted details and/or documents.
3. BM navigates to the Buyer’s account settings or compliance management section.
4. BM updates Buyer’s information:
   • The system allows BM to manually modify:
     • Buyer details (KYC, KYB, AML compliance data)
     • User status (active, blocked, flagged)
     • Account flags (e.g., manual unflagging)
   • The system validates inputs in real-time, checking for missing or incorrect fields before saving.
5. The system saves changes upon successful validation.
6. The system notifies BM with message: “Information has been updated successfully.”

Tasks for BM in Odoo:

1. Check and validate Buyer-provided information or documents (e.g., ID, business registration).
2. Request additional information if needed.
3. Collect information from external sources (googling) for cross-checking compliance.
4. Update Buyer’s profile:
   • Modify KYC/KYB/AML details based on verification.
   • Update user’s status (active, blocked, flagged).
   • Unflag account manually if applicable.
5. Upload and attach verified documents to Buyer’s profile.
6. Add comments or notes regarding the compliance review.

---

Actor(s): BM, Odoo, Agent – Selected individual or company authorized to represent or manage an asset.

Goal:
To onboard a pre-selected agent into the platform’s system, ensuring their profile, documentation, and compliance status are registered and approved for operational involvement.

Preconditions:

• Agent has been pre-vetted and shortlisted by the platform (AM / BM responsibility).
• Legal agreements or terms of engagement have been finalized externally.
• BM has access to agent details and documentation.

Postconditions:

• Agent profile is active in Odoo.
• Agent is associated with particular market(s) and district(s), as well as with one or more assets, and is visible in relevant workflows (e.g., property setup, rental agreements signing).
• All onboarding documents and compliance checks are stored and traceable in Odoo.

Main Flow:

1. BM opens the Odoo Contact module.
2. BM creates a new Contact entry using available templates.
3. BM enters key information:
   • Agent name
   • Contact details
   • Company name (if applicable)
   • Assigned region/asset scope
   • Internal tag/reference (e.g., “Agent”)
   • Description or list of agent responsibilities / provided services
   • Price or cost of agent services
4. BM performs background checks and solvency review (may include external sources like Google).
5. BM checks completeness and accuracy of provided documentation.
6. BM uploads signed agreements, identification documents, and due diligence materials.

Approval & Activation:

• If documentation is complete and approved:
  • BM sets status to “Active”, “Confirmed”, or similar.
  • Agent becomes selectable in property/project workflows.
  • (Optional) BM links agent to specific asset(s).
• If documents are incomplete or invalid:
  • BM requests updates from Agent.
  • Status remains “Pending” or “Incomplete”.
• If not approved:
  • BM sets status to “Not Confirmed” or similar.

---

Actor(s): BM, Odoo, Developer – Pre-approved real estate developer (individual or company) responsible for creating or managing property development projects.

Goal:
To onboard a pre-selected real estate developer into the platform’s system, ensuring their company profile, documentation, and compliance status are registered, and enabling their participation in relevant development and asset management.

Preconditions:

• Developer has been pre-vetted and approved by the platform (AM / BM responsibility).
• A partnership or development agreement has been finalized externally.
• BM has access to developer company and representative details, along with required documentation.

Postconditions:

• Developer profile is active and visible in Odoo.
• RE Developer is linked to one or more projects or assets and participates in relevant workflows (e.g., project setup, asset approval, reporting).
• All onboarding and compliance documentation is uploaded and traceable within Odoo.
• Optionally, a development contract (or similar) is signed between the Platform and Developer by AM, and uploaded into Odoo.

Main Flow:

1. BM opens the Odoo Contact module.

2. BM creates a new Contact entry and inputs:
   • Developer name (company or individual)
   • Contact details and primary representative
   • Company registration details (e.g., trade license, registration number)
   • Region/market of operation
   • Internal tag/reference (e.g., “Developer”)
   • Description of development scope or project types
   • Pricing model, fees, or revenue share terms (if applicable)

3. BM performs due diligence and background checks (may include online research, references, financial solvency checks of company and beneficial owners).
4. BM verifies legal and corporate documentation (e.g., licenses, insurance, project portfolios).

5. BM uploads signed agreements, KYC, company registration, and compliance materials.

6. If all documentation is complete and approved:
   • BM sets developer status to “Active”, “Confirmed”, or similar.
   • (Optional) Developer becomes selectable in workflows like project registration, asset approval, or reporting.
   • (Optional) BM links developer to initial project(s) or asset(s) already onboarded in Odoo.

7. If documentation is incomplete or invalid:
   • BM requests updates from Developer.
   • Status remains “Pending” or “Incomplete.”
8. If not approved:
   • BM sets status to “Not Confirmed” or equivalent.

---

---

Actor(s): Back Office Manager / Administrator, Third-Party Management Company, Odoo

Goal:
To enable the Backoffice team to effectively control and coordinate third-party property management services, ensuring tasks such as signing contracts with tenants, receiving rental payments, preparation, repair, and cleaning.

Preconditions:

• The property is registered in the system.
• A third-party management company is available and vetted.

Postconditions:

• The service is provided to the tenant locally.
• The property management task is completed, and payment is processed.
• Payment records are linked to the property card.
• All actions are traceable in Odoo.

Main Flow:
Task Creation:

1. Back Office staff receive a ticket (or reminder) that rental agreement is finished/begins.
2. Select a tenant needing service (e.g., signing or prolonging a contract).
3. Select a property needing service (e.g., preparing or cleaning).
4. Create a task request for agents detailing the scope, deadline, and priority.

Agent Assignment and Notification:
5. Backoffice assigns tasks to the agent connected with the particular property.
6. Agent receives task notification via app, ticket, or email (TBD).
7. Optionally, agent confirms or declines the task.

Note: Payment processing tasks are described in Block 43.

Execution & Progress Tracking:
8. Agent performs the assigned task.
9. BM or agent (if they have an Odoo account) updates task status (e.g., "In Progress", "Completed").
10. Upload supporting documentation or images (e.g., before/after photos).
11. If agent flags an issue (e.g., unavailable materials), Backoffice assesses and updates or reschedules the task.

Monitoring & Communication:
12. BM monitors status in real-time.
13. Sends reminders or communicates with agent if delays occur.

Task Completion & Validation:
14. Once task is marked complete, BM reviews submissions.
15. Confirms quality and either marks task “Closed” or requests rework.

BM Tasks in Odoo:

• Define needed actions for tenant or property.
• Observe and re-assign vetted third-party management companies if needed.
• Review and approve scope of work and associated costs.
• Understand when service starts.
• Coordinate with tenant, agent, and third party if involved (e.g., plumber).
• Receive info about task completion and tenant satisfaction if applicable.
• Request and upload photos, videos, documents, invoices for accounting.
• Receive payment ticket from management company and register payment in Bank module.
• Verify and confirm payment in bank records.
• Log or attach payment record to property card for traceability.

---

Actor(s): Tenant, Back Office Manager / Administrator, Third-Party Management Company, Odoo

Goal:
To ensure that only eligible tenants are onboarded through proper verification, a legally binding rental agreement is signed, and property management responsibilities are clearly defined and activated.

Preconditions:

• Property is available and listed in the system.
• Agent has been assigned to handle tenant acquisition.
• Terms for the rental agreement are defined.

Postconditions:

• Valid rental agreement is signed and stored.
• Deposit and prepayment for the defined period is received (see Block 43).
• Property is assigned for ongoing management.
• Tenant is onboarded and tenancy begins.

Main Flow:

1. Agent finds and proposes a tenant for the property.
2. Alternatively, tenant is found through advertisement (rental web pages, etc.).

3. Tenant’s basic information is submitted to the platform and/or to an agent.
4. BM reviews tenant data.
5. BM conducts background and solvency checks (e.g., credit, income, previous rental history).
6. If tenant passes, approval is granted to proceed.

7. BM prepares the lease agreement with property, tenant, and financial details based on the draft.
8. Agreement specifies whether the platform or a third-party company will provide services to the tenant and how facility management is organized.

9. Agreement is sent digitally to the tenant and agent.
10. Tenant signs manually or electronically (depending on local regulations).

11. Signed agreement is stored in Odoo.
12. If signed manually, agreement must be scanned and uploaded; the original should be received and properly stored by local subsidiary or HQ.
13. Rental terms and metadata are saved in tenant and property records.

14. Responsibility for day-to-day property management (e.g., maintenance, rent collection) is assigned as per agreement:
    • Platform (in-house team), or
    • Third-party management company.

15. Tenants receive welcome instructions, contacts, and platform access (if applicable), see UC 44-2a.
16. Management team is notified to begin active service.

Alternative Flows:

Tenant Fails Solvency Check:

• BM rejects the tenant proposal.
• Agent searches for a new tenant.

Tenant Delays or Declines Signing and Payment (Deposit and Prepayment):

• BM follows up or cancels onboarding (see Block 43).

BM Tasks in Odoo:

• Accept tenant’s ticket from agent or advertisement webpage.
• Create a new contact card for the tenant in Odoo.
• Fill in required fields:
  • Name
  • Address
  • Contact information
  • Identification document
  • Employment information
  • Bank account details
• Verify tenant background and proof of income (manual review or attached documents).
• MVP2: Generate and send Sumsub verification link to tenant.
• Update tenant’s status to “Confirmed” or “Cancelled.”
• Participate in negotiations and define specific rental contract conditions.
• Generate rental agreement and payment schedule (BM or third-party company).
  • If handled by third-party, BM reviews before proceeding.
• Forward agreement to assigned management company if applicable.
• Save signed agreement in tenant’s contact card and/or property record in Odoo.
• Receive or provide collection of manually signed agreement.
• Assure deposit and prepayment are received by platform (see Block 43).

---

Objective:
To onboard a confirmed tenant after agreement signing by providing necessary information, access, and linking them to the management team.

Actor(s):
Tenant, Back Office Manager / Administrator, Third-Party Management Company, Odoo

Preconditions:

• Tenant has passed all background, identity, and income checks (from UC 44-2).
• A valid, signed lease agreement is available and stored in the system.
• Deposit and prepayment are received (see Block 43).
• Rental unit is marked as available and linked to the tenant in Odoo.
• It is defined whether the platform or a third-party company will handle ongoing property management.
• A contact card with tenant’s personal and legal information has been created in the system.

Postconditions:

• Tenant is fully onboarded and linked to the management team.
• Communication channels and processes are established and operational.

Main Flow:

1. BM notifies the Agent that the tenant has signed the rental agreement and deposit/prepayment has been received.
2. BM creates or updates the tenant’s contact card in Odoo (if not done already).
3. BM gathers any missing information (e.g., passports of all family members).
4. BM enters final lease details: lease term, start date, rent amount.
5. BM links the tenant to the assigned property and management team.
6. BM provides tenants with welcome instructions, contact info, rules, platform access (if applicable).
7. Management company or internal team receives handover notification.
8. Ongoing services (maintenance, rent collection) begin under assigned manager.

BM Tasks in Odoo:

• Review that tenant has a signed agreement, prepayments done, and confirmed status.
• Finalize the tenant contact record with lease details (lease term, rent amount, start date, additional documents).
• Link the tenant to the property and assigned management team.
• Send a welcome package (house rules, contact info, move-in instructions).
• Coordinate start of service delivery by platform or third-party management company.

---

Actors:

• Back Office Manager (BM)
• Platform Internal Acquisition Manager (AM)
• Seller / Real Estate Developer
• Odoo System

Goal:
Ensure all offline property acquisitions initiated by AM are verified, documented, and accurately registered in the back office system to maintain transparency, traceability, and readiness for downstream processes (e.g., rent, development, resale). Support the internal acquisition process by enabling BM to assist before the deal (due diligence, verification) and after the deal (documentation, registration) through Odoo.

Preconditions:

• AM has identified a target property or project.
• Seller/Developer information and preliminary documentation are available.
• Initial negotiations are underway or completed.

Postconditions:

• Acquisition is recorded and confirmed in the back office.
• All legal and financial documents are received by AM/BM and stored in Odoo.
• Property status is updated to reflect readiness for next stages (resale, rental, development).

Main Flow:

1. AM and/or BM check background of seller or RE developer (identity, credibility, legal standing).
2. AM and/or BM review zoning, permits, land registry, legal compliance, and physical property condition.
3. AM and/or BM review preliminary agreements (e.g., reservation, notary agreements) ensuring legal and financial consistency.
4. BM supports execution of pre-sale documents via internal representatives if needed.

5. AM and/or BM and/or administrator confirm bank transfers or escrow settlements have been completed (see Block 43).
6. Receive acquisition confirmation from AM after contract signing; AM confirms deal finalization offline.
7. BM uploads supporting documentation: signed purchase agreement, title deed, proof of payment, due diligence reports, etc.
8. BM updates and records acquisition details (transaction specifics such as price, payment method, date, AM responsible).
9. BM updates Property status from Pre-Deal to Post-Deal (e.g., “Acquired”) — see UC 44-4.
10. BM adds detailed property/project info to Odoo record: type, location, size, ownership, etc.
11. BM assigns property to correct segment (resale, leasing, development).
12. Both AM and BM check title transfer and notarial filings to confirm legal ownership transfer; BM finalizes ownership info.

Alternative Flows:

Incomplete Documentation:

• BM sets property status to “Pending Documents.”
• Tracks pending items separately for Pre-Deal and Post-Deal stages.

Aborted Acquisition:

• BM updates status to “Cancelled.”
• No further action taken.

BM-Specific Tasks in Odoo (in coordination with UC 44-4):

• Create new property/project record (Pre-Deal).
• Verify seller/developer identity and reputation (Pre-Deal).
• Conduct due diligence on property/project (Pre-Deal).
• Review acquisition agreement (Pre-Deal).
• Record and confirm prepayments (Pre-Deal).
• Support agreement signing as needed (between Pre-Deal and Post-Deal).
• Record and confirm payments if needed (Post-Deal).
• Upload all acquisition-related documentation (Post-Deal).
• Finalize property details and change status to active (Post-Deal).
• Verify title and ownership transfer (Post-Deal), noting it may take time after deal closure.

---

Actors:

• Back Office Manager (BM)
• Odoo System

Goal:
Ensure that each property is uploaded with accurate details and categorized correctly so it can be tracked, managed, and used in the appropriate business workflow (sales, leasing, or project development). Enable BM to create a new property record in the back office, enter all required data, and segment the property according to its intended purpose: for rent, development, or sale (MVP2).

Preconditions:

• Property documentation and details are available (address, size, legal status, etc.).
• Property can be in Pre-Deal or Post-Deal status (per UC 44-3).
• Property has been reviewed and is eligible for listing.

Postconditions:

• Property is successfully created and segmented in the back office system.
• Property is ready to be managed or listed based on its assigned purpose.
• All relevant documents and data are attached for future reference.

Main Flow:

1. BM opens the back office and navigates to the Properties module.
2. BM creates a new property entry form.

3. BM fills in:
   • Basic information (title, address, size, type)
   • Location details
   • Financial details
   • Asset sharing/tokenization info (if applicable)
   • Physical and structural info
   • Media and additional attachments
     (Business Inputs for Sprints 3 & 4 reference “Property Onboarding & Metadata”)

4. BM segments the property by purpose:
   • For rent
   • For development
   • For sale (MVP2)
5. BM assigns internal tags or status such as “Under Review,” “Available,” “Pending Development,” “Internal Only.”
6. BM assigns related team or manager if applicable.

7. BM saves the property, making it available for corresponding workflows (leasing, development planning, sale).

Alternative Flows:

Missing Required Data:

• BM is notified of missing mandatory fields and cannot save until complete.

Segment Changed Later:

• BM or other authorized users may update segmentation if the property’s intended use changes.

Aborted Acquisition:

• BM updates status to “Cancelled” and discontinues further processing.

BM Tasks in Odoo (in conjunction with UC 44-3):

• Click “Create New Property” in Properties module.
• Fill in property details: title, address, size, type, legal information, documents, etc.
• Segment the property: select intended use (rent, development, sale - MVP2).
• Attach relevant documentation and media.
• Assign internal tags/status and responsible teams or managers.
• Save the record.

---

Actors:

• Back Office Manager (BM)
• Odoo System

Goal:
To formally register a development project or project stage in the platform’s back office system, ensuring it is correctly linked, documented, and prepared for management throughout its lifecycle.
Enable BM to create and configure projects or stages, linking them to properties or the real estate development pipeline for tracking and management.

Preconditions:

• Basic information about the project or stage is available offline (e.g., type, timeline).
• For project stages beyond the initial one (stage 2 and onward), the associated property or real estate development is already registered in the system.

Postconditions:

• The project or project stage is successfully created and linked to the appropriate property or development workflow.
• All relevant details and documents are stored and accessible.
• The project or stage is available for monitoring by platform personnel.

Main Flow:

1. BM navigates to the Properties module.
2. BM creates a new Project or adds a Project Stage depending on context.

3. Enter:
   • Project name/title
   • Start date and estimated end date
   • Stage quantity and intervals (e.g., monthly, quarterly)
   • Financial details (contract cost, prepayment, stage funding, balance payments, taxes, connection costs, etc.)
   • Associated property or RE development (if available)
   • Project type (construction, renovation, feasibility study, etc.)
   • Description and scope
   • Responsible manager and team

4. Add specific stages, milestones, or project phases (e.g., planning, design, permitting, construction, sale/rent preparation).
5. Assign dependencies or order of execution to stages.

6. Attach permits, design files, financial projections, supplier contracts, and other relevant documents.

7. Set status (e.g., “In Planning,” “Active,” “On Hold,” “Completed”).
8. Assign internal tags for filtering and reporting (if applicable and TBD).

9. Save project or stage record. It becomes visible and available for tracking, reporting, and collaboration.

MVP2 Alternative Flows:

Incomplete Data:

• BM is prompted to complete any required fields before saving the project or stage.

---

Actors:

• Back Office Manager (BM)
• Odoo System (source of asset metadata and status tracking)

Goal:
To transition a property or project stage into a tokenized investment product by defining share structure, pricing, and uploading all required metadata and media. This ensures the asset is fully prepared for distribution and trading on the platform’s Front End.

Preconditions:

• Property or project stage has been fully onboarded and validated in Odoo (see UC44-3 to UC44-5).
• Legal and financial reviews have been completed.

Postconditions:

• All required metadata and media files, including buyer briefs, have been added.
• Asset is ready for tokenization and can be published/listed on the Marketplace via the Front End.

Main Flow (BM tasks in Odoo):

1. BM navigates to the existing property or project stage record in the Properties module.
2. BM inputs Asset Sharing Parameters (see Business Input for Sprints 3 & 4 “Asset Sharing (Tokenization) Details”):
   • Property or Project stage cost (base valuation including costs and taxes), e.g., 190,000 USD.
   • Initial market price used for tokenization and publishing (including platform fees), e.g., 200,000 USD.
   • For projects, stage-based pricing model (dynamic share prices per stage), if applicable.
   • Maximum Token Supply (total tokens representing the property), e.g., 20,000 tokens.
   • Initial Token Price (value per token), e.g., 10 USD.
   • Currency used for valuation and transactions.
   • Expected market price at end of project development or property lifecycle, e.g., 390,000 USD.
   • Sale window (optional).
3. Once all data is entered, BM updates the asset status to “Available for Publishing”, making it eligible for tokenization and Front End publishing.

---

Actors:

• Back Office Manager (BM)
• Treasury Account (holds the created tokens on behalf of the platform)
• Core System (processes tokenization logic and updates the Ledger)
• Frontend Marketplace

Goal:
To facilitate the sale of tokenized shares for a property or project via the platform’s Marketplace, ensuring proper Treasury handling, internal publishing validation, and synchronized ownership records across systems.

Preconditions:

• Property or project stage is fully uploaded and marked “Available for publishing” (see UC44-3 through UC44-6).
• Treasury Account is available and properly configured to hold the initial token supply.
• All buyer-facing content (images, buyer briefs, documents) is complete and uploaded.

Postconditions:

• Tokens representing the property/project stage are created and allocated to the Treasury Account.
• Asset and share offerings are published on the Frontend Marketplace.
• Buyers can view, add shares to the basket, and purchase available shares.

Main Flow:

• BM1 accesses the registered property/project in the Odoo Properties module.
• BM1 submits the asset for internal publishing approval by BM2 (4-Eye Review).

• BM2 receives a publishing review task in Odoo.
• BM2 verifies:
  • Tokenization parameters (from UC 44-6).
  • Buyer briefs and media (images, documents).
  • Legal and financial completeness.
• If all criteria are met:
  • BM2 finalizes publishing by pressing the designated action button (ensuring role separation between submitter and reviewer).
• If any information is missing:
  • BM2 completes or coordinates necessary updates before proceeding.

• After BM2’s approval, asset metadata, documents, pricing, and share supply are pushed to the Frontend Marketplace.
• Core system updates the asset status to “Live for Purchase.”
• The system syncs data to Core, which:
  • Registers the asset on the Ledger.
  • Divides the asset value into shares.
  • Allocates the full token supply to the configured Treasury Account.
  • Logs metadata (Property ID, share count, price, timestamp).

Buyers can now:

• View the published asset.
• Review pricing, documents, and availability.
• Add desired shares to the basket.
• Proceed with purchase.
  (See UC 14-1: Purchase Shares of Property or Project Stage (1-..) from Token "Treasury" in Self-Service, including repurchase of profits).

Validation Rule:

• Only assets marked as Published can be tokenized. The system must not issue tokens for any property or project that has not been published.

MVP2 Alternative Flows:

• If tokenization parameters change after review, only BM1 (not BM2) can reconfigure and resubmit for approval.
• If validation fails, the asset remains in draft or pending status until resolved.