Transactional capabilities
6 of 6 disabled
Enforced at server boot, not in the interface.
Compliance posture
Habi handles no money, verifies no identities and executes nothing. That is enforced by code that refuses to start a server with a transactional capability switched on. Everything below is either a control that exists in this product today, or a launch blocker labelled as one.
Transactional capabilities
6 of 6 disabled
Enforced at server boot, not in the interface.
Client money handled
None
No payment, escrow, custody or distribution path exists.
Identity decisions made
None
Identity providers are mock. Nobody is approved or rejected.
Sensitive actions logged
All of them
Actor, role, IP, user agent and request id, per action.
6 capabilities could turn this from research software into a regulated financial service. Each one is behind a named server-side switch that is off unless its value is exactly "true". A startup assertion runs before the server serves its first request: if any of them is on, or the live transactional stage is configured, the process throws and the server does not start.
That is the difference between a claim and a control. A hidden button can be un-hidden; a server that refuses to boot cannot be talked round.
PAYMENTS_ENABLEDDisabledAccepting, holding or moving money.
No payment provider is connected. Nothing can be charged or transferred.
LIVE_KYC_ENABLEDDisabledReal identity decisions about real people.
The identity provider is a mock. No document is verified and no applicant is approved.
SECURITIES_EXECUTION_ENABLEDDisabledIssuing, allocating or transferring securities.
Investment-shaped actions are stored as non-binding demo intent records only.
E_SIGNATURE_ENABLEDDisabledSignatures that bind a person to a document.
Nothing on the platform can be signed. Acknowledgements are consent records, not contracts.
SECONDARY_TRADING_ENABLEDDisabledMatching buyers and sellers of existing holdings.
The secondary-market screens are a design study. No order is matched or executed.
REAL_DISTRIBUTIONS_ENABLEDDisabledPaying rent or sale proceeds to participants.
Distribution figures in the dashboard are demo data. No payout is scheduled or made.
Switch names and behaviour live in src/lib/launch.ts and the boot hook in src/instrumentation.ts. This list is generated from that same source, so a new capability cannot appear in the codebase while this page still claims there are 6.
Duties under the Prohibition on Money Laundering Law, 5760-2000, attach to defined financial activity. Habi performs none of it: no funds are accepted, no account is held for anyone, and no value moves between people.
The onboarding flow exists so the experience can be designed and tested. It is not an identity decision. No document is inspected, no database is queried, and nobody is approved or rejected — the word "approved" is banned from this product's vocabulary while that remains true.
Collects the profile fields a future check would need, shows the shape of the journey, and records progress so the design can be reviewed.
It does not verify a document, score a risk, decide eligibility, or create any status that another part of the product could rely on.
A regulated provider, a documented decision and appeal path, human review of edge cases, and a data protection impact assessment covering identity documents.
Habi is the controller of the personal data it holds, under the Privacy Protection Law, 5741-1981, as amended by Amendment 13, which came into force on 14 August 2025 and substantially widened controller duties, enforcement and penalties. The Privacy Protection (Data Security) Regulations, 5777-2017, set the security duties underneath it. Visitors in the European Union keep their GDPR rights over the data they give us, including access, rectification, erasure, restriction, portability and objection.
Full details are in the privacy policy. Data rights requests can be made at any time through the contact page.
A compliance claim you cannot evidence afterwards is not a control. Sensitive actions here are written to an audit log as they happen, and the record is designed to outlive the personal data it refers to.
The action, the entity it touched, the acting user and their role, the IP address and user agent, and a request id that ties it to the server logs.
Audit rows reference an internal user id rather than personal details, so anonymising a person leaves the trail intact without keeping their data.
Every request carries an id through the structured logs and back out in the response header, so a single user report can be reconstructed exactly.
Private, admin and internal responses are marked not to be stored, and internal-only fields never cross into a browser bundle.
The controls below are implemented, not aspirational. They are listed at the level a reviewer can check against the code.
Signed, HttpOnly cookie sessions for both the public product and the internal workspace. Session material is never readable by page scripts.
Every mutating browser endpoint validates the request origin against the configured application URL and requires an explicit header before it will act.
Shared, cross-instance limiting in production; a process-local limiter is rejected there because per-instance counters limit nothing when several instances run. The limiter fails closed — an outage denies rather than opens.
Form submissions carry an idempotency key, so a double click or a retried request produces one record rather than two.
A production server refuses to start on a localhost URL, a SQLite database, a plaintext admin password, a demo secret, a memory-only rate limiter, local document storage, or a mock provider standing in for a live one.
Structured logs carry a request id end to end, error reports are redacted of personal data, and private, admin and internal responses are marked not to be cached. Vulnerabilities have a private reporting channel with published acknowledgement targets.
The structural question for any platform that both selects deals and earns from them is who gets paid when things go badly. The intended answer is written into the fee model, and it is published rather than buried.
The planned success fee applies only to profit above a 6% annual return to participants. Below that hurdle Habi earns no success fee at all. A hurdle aligns incentives; it does not promise a result, and a deal can return less, nothing, or a loss.
Each property is planned to sit in its own company, separate from Habi's own entities. Habi is designed as the operator of the platform, not as the counterparty holding your money.
Nothing in the opportunity list is ranked, promoted or featured because of what Habi would earn from it, and no third party pays for placement. Ordering and filtering rules are the same for every listing.
If Habi, its people or their relatives have any interest in an asset, a seller or a service provider, that interest must be disclosed on the opportunity itself before launch. A staff dealing and personal-account policy is a launch blocker.
The full fee model, with a worked example, is on the fees page.
Marketing is where a platform like this one most easily breaks the law, so the vocabulary is a written rule rather than a matter of taste. It is enforced in review on every page of the product.
Four named channels, each a monitored queue with an owner and a target rather than an inbox someone might read. Anything framed as a legal demand, a regulator reference or a formal complaint is copied to the legal and compliance queue and assigned to the compliance owner the same business day.
| What it handles | Channel | Response target |
|---|---|---|
| General product and beta questions | support@habi.example | First response within 1 business day |
| Data access, correction, deletion, consent withdrawal | privacy@habi.example | Acknowledged within 1 business day; statutory deadline tracked by counsel |
| Vulnerabilities, suspected account takeover, abuse | security@habi.example | Critical reports acknowledged within 1 hour |
| Accessibility barriers and accessible alternatives | accessibility@habi.example | First response within 1 business day |
The habi.example domain is a reserved documentation domain and cannot receive mail. These addresses are placeholders until the production domain is registered and verified — until then, use the contact form, which is monitored.
Support runs Israeli business hours, Asia/Jerusalem. Outside them, only critical security reports and severe incidents are actioned. Go to the contact page
The route Habi intends to prepare with counsel. Nothing on this path is active. It is published so that the shape of the plan can be challenged before it is built, not to suggest that any of it is done.
Israeli law lets securities be offered without a prospectus to investors who meet the statutory criteria, plus a limited number of other offerees in any twelve-month period. Habi plans to operate strictly inside those limits, with offeree counting tracked and enforced in our internal systems before anything specific is shown.
Each offering is planned as a dedicated property company. Participants would hold shares of that company only. An external trustee and a lawyer-supervised escrow account would stand between participant money and any transaction, and each company would file audited annual reports.
Regulatory guidance counts offerees across related entities and intermediaries, so exposure to a specific offering has to be gated and logged rather than broadcast. This is the reason the public site never becomes a shop window for a live deal.
For participants outside Israel, an offer could be made only where local securities law permits it. Country-based eligibility checks would run before any offer, and local tax and reporting duties would be flagged to the participant rather than glossed over.
Return language on this platform is always a target, never a promise. The planned underwriting filter and the success-fee hurdle are internal standards that align interests. They guarantee no result, and real outcomes can be lower, zero, or a loss.
Five control areas, each split into what exists in the product now and what still blocks a public launch, with the official source for the law behind it.
In the product: Every investment-shaped action is captured as a non-binding demo record. There is no prospectus flow, no payment settlement and no securities transfer anywhere in the product.
Launch blocker: Licensed review of the legal structure, validation of the offering-coordinator or crowdfunding route, and a final reading of which exemption applies.
In the product: The interface and the APIs are labelled education-only. Neither the written content nor the AI analyst tells a specific person that a specific investment suits them.
Launch blocker: A legal determination of where regulated advice begins, a licensed-role model, and supervised disclosure wording for production.
Advice, Marketing and Portfolio Management Law, 5755-1995 — ISA section
In the product: Sign-up requires terms and privacy consent and the acceptance is persisted; audit logs are written for sensitive flows; retention windows and a deletion path exist in code.
Launch blocker: A counsel-reviewed retention schedule, an impact assessment, a data protection officer where required, and a formal incident playbook.
Privacy Protection Law, 5741-1981 — gov.il translation (PDF)
In the product: The product blocks real-money onboarding, transfers and settlement by design, which keeps the activity that triggers these duties out of scope for now.
Launch blocker: A regulated identity and screening provider, risk-based onboarding, sanctions and politically-exposed-person screening, and a suspicious-activity escalation path.
Prohibition on Money Laundering Law, 5760-2000 — gov.il (PDF)
In the product: RTL-aware layouts, semantic structure, visible focus states, contrast checked against the real surfaces, and a published accessibility statement.
Launch blocker: A full external accessibility audit, tracked remediation, and publication of a named accessibility coordinator.