You're about to run your tenants' rent through software you haven't used before. Here is exactly what happens to it, and what we can and cannot see.
Every rent charge is created directly on your business's own Stripe account. You're the merchant of record, the payment settles to your Stripe balance, and Stripe pays it out to your bank. It never passes through an account Rentarina holds. We are not a bank, a money transmitter, or an escrow agent, and we are not structured to become one.
On bank transfer, the tenant pays 1.5%, which covers Stripe's cost and ours, and Stripe deducts it from that same charge. On card, the only fee is Stripe's standard processing cost; there is no Rentarinafee. Each payment is recorded with three amounts: Stripe's processing cost, the total fee taken from the charge (which includes that cost), and the fee the tenant paid.
Stripe runs your business verification through its own onboarding, embedded in Rentarina. Stripe holds your identity and bank details, and we store only the verification status. Payouts run on the schedule Stripe sets for your account; Rentarinadoesn't set, hold, or redirect them.
A lease records the security deposit amount. Rentarinadoesn't collect, hold, or return deposits.
This is the part we'd want to see if we were buying this.
Every database query is scoped to your organization before it runs. Behind that, Postgres row-level security enforces the same boundary on its own: 47 policies across the schema, which return nothing at all when no organization is set. In production, the application connects as a database role that doesn't own those tables and can't bypass row-level security. Two separate mechanisms, either of which would stop a leak on its own.
Tenants see their own lease, their own payment history, their own maintenance requests and documents. Not another tenant's, not another landlord's. Document downloads and receipts check the requesting tenant against the record before returning anything, so changing an ID in a URL returns a 403, not a file.
We test this. Our test suite includes cases that attempt to reach another organization's rows by ID and confirm they fail, and cases that confirm the database role can't disable the policies protecting them.
The safest place to keep sensitive data is somewhere you aren't. Most of the security work here was deciding what not to hold.
We do not use your data, your tenants' data, your leases, or your payment records to train AI models. Not ours, not a vendor's.
Rentarina AI reads your data to answer your questions and draft your messages. Those requests run under commercial API agreements that carry no training rights. Nothing you put into Rentarina makes a model smarter.
No message RentarinaAI drafts reaches a tenant until you've read it and pressed send. In Ask, the only changes it can prepare are resolving a maintenance request and recording an off-platform payment, and neither is written until you confirm.
Three things run without that step. It sorts new maintenance requests by category and priority. It reads expiry dates off the documents you upload and marks them as they come due. And tenants can ask it about their own lease, with the answer going straight to the tenant.
Anything a tenant writes is passed to the model as data, fenced off from its instructions. Every AI call is logged against your account.
SOC 2 reports are confidential by design — there's no public registry for any vendor, ours included. Each of these publishes a trust center and releases its report under NDA. Stripe and Anthropic also publish public SOC 3 summaries anyone can read.
This is the complete list. Not a sample, not the notable ones. We tell you before it changes.
Our staff cannot act on your account without leaving a record.
Every change, export, support session, and disclosure of tenant contact information is written to an append-only log with the staff member who did it and the reason they gave. The reason is mandatory — the system rejects the action without one. The log records what changed, from what to what, the IP address, and the browser. A database trigger rejects edits and deletions to that log.
Support sessions are read-only by default. Enabling writes inside one is a second, explicit action, and it is logged separately.
Our internal console reads across accounts through a separate database role that can only read, granted table by table. Every change the console makes to an account is tied to a named staff member and a reason in the same log.
Rentarinais not itself SOC 2 certified. We're a new product and we won't pretend otherwise. What we can tell you is which decisions we made — not custodying funds, not storing IDs or SSNs, isolation enforced twice over, an audit log the database refuses to edit — and those are structural. They aren't promises about a future audit.
No system is perfectly secure. If you find a vulnerability, or see access under Support access you can't account for, write to support@rentarina.com.
Questions your CPA, attorney, or insurer would ask? support@rentarina.com