§ Legal

Privacy Policy

Last updated · October 2026

This Privacy Policy explains what information (Fiop Super Intelligence) collects when you visit this website, contact us, or use the platform; how we use it; who we share it with; and the choices and rights you have. does the processing, underwriting, closing and servicing work for private real estate lenders, and a person approves every binding step. We collect the minimum we need, we never sell personal information, and we never use it for advertising.

What this policy covers

Fiops, Inc. ("", "we", "us") operates this website (fiops.ai) and the platform, meaning the workspaces our customers run and the accounts people use to sign in to them. This policy covers both.

We play two roles. For visitors to this site and for the account details of people who sign in to the platform, decides what is collected and why, so we are the controller of that information. For the content a customer puts into its workspace (records of loans, borrowers, documents and messages), the customer decides; processes that content on the customer's behalf and under its instructions, so we are the processor of that content.

A customer's own privacy notice for its borrowers is a separate, per-customer document and never lives on this page. If you are a borrower working with a lender that uses , that lender's notice governs what it collects from you and why.

Information we collect on this website

When you fill in the form on our homepage, we collect the name, work email, company and note you provide and the role you choose from the short list. The submission is delivered to us as an email to hello@fiops.ai, together with the IP address, browser type, referring page and time of the submission, so we can respond and tell genuine requests from automated ones. The website itself does not keep a copy in a database.

If you enter an access code, we check it against our list and keep only the outcome. The code is not logged or stored.

If you contact us by email, we keep the correspondence so we can reply and keep a record of what was discussed.

Information we collect when you have a platform account

When your organization provisions a workspace and you create an account, we collect what is needed to run it: your name, work email, role, team and workspace membership, your sign-in method and security details (such as passkeys and registered devices), and security signals such as sign-in events.

If you sign in with your Google account or another identity provider, we receive the email address and basic profile that provider returns and use them to identify your account. This sign-in step is separate from connecting a Google account to the platform, which is described in its own section below.

We also collect service data: how features are used, performance measurements, error logs and diagnostics. Before error reports and logs leave the platform, passwords, tokens and similar values are removed from them.

If you use Astor, the platform's assistant, your conversations with it are stored in your workspace so you can return to them. Borrowers can clear their own Astor conversation history from the borrower portal.

Content customers process in their workspaces

Customers use their workspaces to manage their own business records, which can include personal information about their borrowers, guarantors, partners and vendors. processes that content on the customer's behalf and under its instructions. The customer decides what is collected and how it is used, and the customer's own privacy notice governs it.

Each workspace is isolated to the customer it belongs to: every record is tagged with the workspace it belongs to and every query is limited to that workspace. We do not use one customer's data to serve another, and we do not sell workspace content or use it for advertising.

Many of our customers are financial institutions. When we receive nonpublic personal information from one of them, we act as its service provider: we use and disclose that information only to perform services for that customer, as the Gramm-Leach-Bliley Act and its Privacy Rule allow, and we protect it with the safeguards described under Security.

Categories of personal information

The list below summarizes the categories of personal information we have collected in the past twelve months and continue to collect, where each comes from, and who receives it. We collect each category for the purposes described under How we use information and keep it for the periods described under Data retention.

  • Identifiers and contact details, such as name, work email, phone number, account identifiers and IP address. Sources: you, your organization and your browser. Recipients: our hosting, email-delivery and error-reporting providers, and our text-message provider when a workspace sends SMS.
  • Professional information, such as company, role, team and workspace membership. Sources: you and your organization. Recipients: our hosting provider.
  • Account credentials and security information, such as your sign-in method, passkeys, registered devices and sign-in events. Sources: you and your browser. Recipients: our hosting provider; credentials are never disclosed to anyone else.
  • Internet and device activity, such as pages requested, browser type, timestamps and error reports. Source: your browser. Recipients: our hosting and error-reporting providers.
  • Communications and documents, such as email, files and calendar entries you choose to bring into a workspace from a connected account, and messages you write in the platform. Sources: you and your connected accounts. Recipients: our hosting provider and, for a feature you use, an AI provider under the no-training restriction described below.
  • Financial and loan information, such as the loan, property, income and payment details a lender records about its borrowers, and the government identifiers it collects for its own legal duties. Source: the customer that controls the workspace. Recipients: only the providers listed under How we share information, on that customer's behalf.
  • Sensitive personal information, meaning account credentials and government identifiers, is used only to provide and secure the service and is never used to infer characteristics about you.
  • Inferences: we do not build profiles about you or draw inferences to predict your behavior or preferences.

Cookies, local storage and information collected automatically

This website sets no cookies and runs no analytics, advertising or session-recording tools. Once per browser session it sends us the path of the page you landed on, nothing else, and we keep only a daily count of visits per page with no identifier attached. Apart from the error reports described below, the site does not track you, there is nothing for a Do Not Track or Global Privacy Control signal to switch off.

Your browser loads our typefaces from Google Fonts, and the address fields inside the platform load Google's address lookup, so Google receives your IP address as part of those requests.

The signed-in apps keep your session token in your browser's local storage. They also set a few cookies the service needs in order to work, and none is used for tracking or advertising: has_auth and user_role record that you are signed in and which kind of account you use, so the right pages load; theme-mode remembers whether you chose the light or dark theme; custom-domain-business-id tells the app which lender a custom web address belongs to; and one cookie set during an electronic-signature invitation proves the signing page was opened from the link you were sent.

Like any online service, our servers and hosting provider keep standard request logs (IP address, browser type, pages requested, timestamps) for security and reliability, and we use your IP address for a short time to limit abusive request rates. If something fails, an error report may be sent to our error-monitoring provider; for a signed-in user that report can include your account identifier and email and the request that failed, with passwords, tokens and similar fields removed before it is sent.

How we use information

We use information to provide the service: to run your workspace, sign you in, deliver the features you and your organization choose to use, and keep the record of what was done and by whom that lending work requires.

We use the details you submit on this site solely to reply to your request, evaluate fit, and communicate with you about working together.

We use information to keep the service secure: to detect and limit abuse, investigate incidents, and maintain an audit trail.

We use aggregate usage and error information, and de-identified data as described under De-identified data, debugging and model improvement, to maintain, debug and improve the service. We do not use personal information, workspace content or data from your connected accounts to build marketing profiles or to serve advertising.

We use your contact details to send service notices about your account or workspace, and we use information where the law requires us to.

Legal bases for people in the EEA, the UK and Switzerland

Where European data protection law applies, we rely on these legal bases. Performance of a contract: running the workspace and account you or your organization asked for. Legitimate interests: securing the service, preventing abuse, responding to inquiries and improving the service, balanced against your rights. Consent: connecting a Google account or another personal account, and any optional feature you turn on yourself; you can withdraw consent at any time by turning the feature off or disconnecting. Legal obligation: where a law requires us to keep or disclose information.

Where is the processor for a customer's workspace content, the customer is responsible for its own legal basis, and we act on its instructions.

Google user data (Gmail, Google Drive, Google Calendar)

Staff users of a customer's workspace can choose to connect their own Google account to the platform. This is always optional, always personal (the connection belongs to you, not to your organization, and is scoped to one workspace), and always permission by permission: we ask Google only for the permissions needed for the features you turn on, and we ask for additional permissions (such as sending mail as you) only when you turn on a feature that needs them. Google shows you exactly what is requested each time, and you can decline any of it.

Google user data is used only to provide and improve these user-facing features for you and your organization. We do not use it for advertising and we do not sell it. Google Workspace APIs are not used to develop, improve or train generalized or non-personalized AI or machine learning models, and neither is any data aggregated, anonymized or derived from them (see De-identified data, debugging and model improvement below).

Fiops' use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements. You can read that policy at https://developers.google.com/terms/api-services-user-data-policy.

No one at reads your Google data in the ordinary course of operating the service. The only exceptions are the ones Google's policy allows: with your explicit consent, for security purposes such as investigating abuse, to comply with the law, or on aggregated and de-identified data for internal operations. The people who can see what was brought into the platform from your Google account are you and, for items filed to a loan record, the colleagues in your organization who can open that loan; a message placed in a loan's message thread is also visible to the borrower on that loan at the sharing level you chose. Administrators see only the summary information described under How Google user data is stored and protected.

Here is what we access from each Google product and why.

  • Google account (email and profile). When you connect, we ask Google for your account's email address, basic profile and a stable account identifier. We store the address and the identifier so we can show which account is connected, tell a reconnection of the same account from a different one, and check the address against your organization's email domain where its policy requires that. We do not store your name or profile picture from this step, and we refuse the connection if Google has not verified the address.
  • Gmail, reading (gmail.readonly). Used to file mail that belongs on a loan record, to notice when someone replies to a follow-up you sent from the platform, and to let Astor answer questions and draft replies from your own mailbox when you ask it to. Filing and Astor's reading are separate switches you control, off by default; reply detection runs for the follow-ups you send from the platform. Two housekeeping reads also happen: a count of messages sent and received in the last 7 days, shown to your administrators, and, when Google's answer to a send was lost, a check of your Sent folder (or of the thread Astor replied on) to confirm the message went out. We read only what the feature needs: first a message's headers and labels, then the full message only when it may belong on a loan record or needs a security check. We never read mail in labels or from senders you tell us to leave alone, and we drop newsletters, promotions, social updates and other automated mail without reading their body. We never change your mailbox: no marking as read, labeling, archiving or deleting.
  • Gmail, sending (gmail.send). Used to send email from your own address when you, or Astor on your instruction, choose to send from the platform, for example a reply to a borrower or a scheduled follow-up your organization has set up. We ask for this permission only when you set up a feature that sends mail or turn sending on later, and your organization's policy decides which roles may grant it. The sent message lives in your Gmail Sent folder. Of the send itself we keep only message identifiers, recipient counts and timestamps; if the message was written in the platform, the text you or Astor composed stays with the loan record it was written on, and sent mail may be filed to a loan as described in the next section.
  • Google Drive (drive.readonly). Used to bring files from a Drive folder you choose into a loan record. We ask only for read-only access, we never browse your Drive, and we act only on a folder link you paste. We list the names, types, sizes, modification dates and sharing details of what is in that folder, and we copy only the files you tick. We never create, change, share or delete anything in your Drive.
  • Google Calendar (calendar.events). Used to put meetings you have accepted onto the plan of the loan they relate to. We read only your primary calendar, only events that change after you connect (never your history), and from each event we request only its identifier, title, location, start time, status, organizer and attendee list. Event descriptions, attachments and meeting links are never requested. Although the permission Google grants can also create and edit events, the platform does not currently create, change or delete anything on your calendar.

What happens to Gmail, Drive and Calendar data inside the platform

Mail filing works like this. When you turn mail capture on, the platform checks your inbox (and, unless you switch it off, your sent mail) at the interval you choose, starting from the moment you turned it on, plus a one-time look back of up to 30 days where your organization's policy allows it. A message is filed to a loan only when it clearly belongs there: the sender is a known contact in your workspace, the thread is already on a loan, or the message names the loan. Mail that cannot be placed is not filed and is never put on a shared queue; it waits in a private list only you can see.

What is kept on the loan record is up to you. By default we store one generated line (for example, a contact emailed about a subject), the sender address and the attachment names, and the body of the email stays in your Gmail. You can narrow that to attachment facts only or widen it to the full text of the message. Whatever setting you choose, we also keep the message's subject, the addresses it was sent to and copied to, and its threading identifiers, so replies land on the same loan. Attachments on a filed message are copied to the loan's documents at every setting, except small inline images such as signature logos. A message that asks to change wire, payoff or bank-account details is set aside for your review and is never filed automatically; where your organization's policy allows it, a short alert naming the sender and the kind of change requested (never the message itself) is also posted to the loan that contact is on, so colleagues are warned.

Once filed, a message, its attachments and a short card about it are part of the loan record and visible to the colleagues who can open that loan. A filed message is placed in the loan's message thread, which the borrower on that loan can also open, at the sharing level you chose; this includes mail you sent that we filed. Mail we only counted or could not place is never shown to anyone but you, apart from the wire, payoff or bank-account alert described above.

Drive files you import are copied, not synced, into the platform's own document storage, where they are converted to text, indexed for search within your workspace, and read for their document type and key fields so they can be matched to the right slot on the loan. A person confirms where each file goes; nothing on the loan is satisfied or approved by the import itself. We keep the folder link you pasted (encrypted in the import ledger, and as plain provenance on each imported file) together with the name and address of the person who shared the folder, so you can finish an import later or check the folder for new files; we read that folder's listing again only when you or a colleague opens the loan's documents or asks us to check again, and never after you tell us to stop reading it. Imported files are internal to your organization by default and are not shown to borrowers unless a colleague chooses to share them.

Calendar events become part of a loan only when you have accepted the meeting and it ties to exactly one loan; the result is a plan item and a card in that loan's room. Your organization sets a ceiling, and beneath it you choose whether we tie events to loans by title and location only, or also match attendee addresses against the staff and borrowers in your workspace. Attendees who match are shown by name; addresses that do not match are shown as unmatched on the card. If you decline a meeting or the organizer cancels it, the plan item is marked cancelled. Calendar data is kept nowhere else, and no AI model is involved in calendar matching.

How Google user data is stored and protected

Your Google access and refresh tokens are stored in our database, which runs on Google Cloud, encrypted at the application layer with AES-256-GCM using keys kept in a managed secret store separate from the database. New tokens are sealed with a key bound to your workspace, your user and the field they belong to, so a copied ciphertext cannot be reused anywhere else; tokens stored before this safeguard was added are re-sealed when you next reconnect. All traffic between your browser, our services and Google's APIs is encrypted in transit.

Mail and calendar data pass through our services in memory and are written in the forms described above: filed messages and cards on the loan record, copied attachments and Drive files in our document storage, plan items, the receipts, counters and cursors that let the feature resume where it left off, the sender-to-loan rules you teach us, drafts held for your review, and, when you ask Astor to read your mailbox, the excerpts Astor quotes in that conversation.

Tokens are never written to logs or audit records. Gmail and Calendar reads are recorded in an append-only audit log that holds the kind of call and at most one message or thread identifier, never message bodies, subjects or attachments; Drive imports are audited per import and per folder check. The Activity tab of Connected accounts lists what was filed from your account and the on-demand reads made for you, such as a thread Astor opened at your request or a check for replies to a follow-up you sent; the scheduled scan itself and calendar reads are recorded in that audit log as counts, and your Mail & calendar room shows each pass's totals.

Administrators in your organization can see that you have connected an account, the connected address, its status, the permissions you granted and summary counts; with the right permission they can also see a list of recent items filed from your mailbox and drafts written for you (subject lines and counterparties, not message bodies). They cannot open your mailbox, Drive or calendar and cannot use your connection; they can only disconnect it. support enters a workspace through a consent request that a user in that workspace approves; the grant is time-limited, read-only by default and audited.

How long we keep Google user data and how it is deleted

Tokens and connection settings are kept only while the connection exists. Disconnecting in the app, being removed from the organization, or an administrator revoking the connection deletes them immediately. We revoke the grant at Google at the same time; if Google cannot be reached, we still delete our copy and tell you that the revoke at Google did not go through. The list of what was filed from your account (record, subject line and sender name) stays visible to you after you disconnect and is kept with your organization's workspace records, and a scan bookmark holding no mail content (an opaque page marker and timestamps) may remain as well.

For mail we looked at and did not file, we keep no copy of the message. For mail we could not place, a receipt with the sender, subject and time is shown to you for up to 60 days and then no longer displayed; it is kept afterwards in your organization's workspace records until the workspace is closed. A message set aside for a wire, payoff or bank-account change is listed for your review for 30 days; its sender, subject and the kind of request are kept afterwards in your organization's workspace records until the workspace is closed. For mail we only counted, such as newsletters and automated notices, no sender or subject is kept at all.

Items filed to a loan record (messages, attachments, Drive files and calendar plan items) become part of your organization's records and stay with the loan when you disconnect, so the record remains whole. They follow your organization's handling of that record: you can undo a filing or a Drive import within 24 hours, which takes the items off the loan and marks the message as withdrawn, though the message stays in the thread as a record and a copied file remains in our document storage until a colleague with permission deletes it; filed items are otherwise kept for as long as the loan record exists; a colleague with permission can delete a document, which destroys the stored file along with its search index and extracted fields; and when your organization closes its workspace, its records are exported and deleted as its agreement with us provides.

Audit records of what was read and filed hold identifiers and counts rather than content, and are kept for at least the period your organization's regulatory obligations require.

Revoking Google access

In the app, open Personal controls and then Connected accounts. There you can switch Calendar or Drive off for the platform's use without a trip to Google (the switch takes effect at once), turn mail capture and the other mailbox switches off, or choose Disconnect, which revokes the grant at Google and deletes the stored tokens and settings. Your organization's administrator can also disconnect your account from the team's email connections page.

At Google, you can remove Fiops' access at any time at https://myaccount.google.com/permissions. If you do that without disconnecting in the app, the stored token stops working immediately and the connection shows as needing reconnection; use Disconnect in the app to delete the stored record, or email hello@fiops.ai and we will remove it for you.

Revoking access does not remove items already filed to loan records. Those are part of your organization's records and are handled as described in the previous section.

Artificial intelligence features

Some features use large language models: matching an email to the right loan when the plain rules cannot, writing the one-sentence note that accompanies a filed email, drafting replies you ask Astor to write, reading documents for their type and key fields, proposing where files from an imported Drive folder belong from their names, folder paths, types and sizes, drafting an acknowledgment to a question filed to a loan where your organization turns that on (it waits for a person), and answering your questions in Astor. These run only to serve the feature you or your organization use. A draft Astor writes waits for a person unless you have expressly turned on sending on your behalf and your organization's policy allows it, and a change Astor proposes to a loan record waits for a person's approval.

The models are provided by third parties. Anthropic is the default provider for language features; Google (Gemini) is the failover and also provides embeddings (the numeric representations that power search), speech-to-text and reading document layouts; and OpenAI may serve specific tasks where a per-task routing setting sends them there. When a feature needs it, the relevant text (for example a limited excerpt of an email body or of a document) is sent to the provider, which returns a result. When the plain rules cannot place a message from a known contact, a limited excerpt of its text is sent to the provider to rank candidate loans, whatever sharing level you chose; the platform keeps no copy of the text from that step. We send only what the feature needs, on several of these paths we remove Social Security, tax, card and credential numbers before sending, and our providers are contractually prohibited from using your data to train or improve their models.

Our AI providers do not train their models on the data we send them. may use de-identified data, never Google user data, to develop, evaluate and train the models and rules that power features, as described under De-identified data, debugging and model improvement. For each request we keep metadata (model, token counts, timing and cost) for billing and reliability, and a cache that lives for a few minutes to avoid sending the same request twice.

Automated decisions

does not make decisions about you that produce legal or similarly significant effects based solely on automated processing. The platform prepares work for the people at a lender, and a person approves every binding step.

Any decision about a loan, including whether to offer credit and on what terms, is made by the lender that uses the platform, not by . If you have a question about such a decision, contact that lender.

De-identified data, debugging and model improvement

To keep the platform working and to make it better, we create de-identified and aggregated data from the information we process. De-identified data has names, contact details, account and loan numbers, government identifiers, property addresses and other direct identifiers removed or replaced, and is processed so that it cannot reasonably be linked to a person, a household or a customer. Aggregated data combines many records so that no single record can be singled out.

We use de-identified and aggregated data to investigate and fix defects, to measure accuracy and reliability, and to develop, evaluate and train the models and rules that power features, such as recognizing document types, reading fields from documents and matching messages to loans. We do not sell it, use it for advertising, or use it to identify or contact anyone.

We maintain and use de-identified data only in de-identified form and do not attempt to re-identify it, except to test that our de-identification works, as the law permits. Anyone we share it with is contractually bound to the same commitments.

Google user data is excluded. Data obtained through Google Workspace APIs (Gmail, Google Drive and Google Calendar), and anything aggregated, anonymized or derived from it, is never used to develop, improve or train generalized or non-personalized AI or machine learning models.

When a defect or security issue cannot be diagnosed from de-identified data, a small number of authorized engineers may examine the specific records involved, limited to what the investigation needs. We also review samples of Astor's answers and suggestions to check their accuracy; content obtained from a connected Google account is read by a person only to investigate a bug, abuse or security issue, with your consent, or as the law requires.

A customer can ask us to exclude its workspace data from model development and training by emailing hello@fiops.ai. We confirm the request and apply it going forward; it does not change the features the workspace can use.

How we share information

We do not sell personal information and never have. We do not share it with advertisers or data brokers. We share information only with the service providers that help us run the platform, with your organization, with integrations your organization chooses to connect, with your consent, to protect the service, or when the law requires it. If is ever part of a merger, acquisition or sale of assets, information may be transferred as part of that transaction and will remain subject to this policy.

Google user data in particular is shared only with the providers that host, secure and monitor the platform and, for an AI feature you use, with the AI provider serving that request under the no-training restriction above; where your organization routes such notices to Slack, a notification that a message was filed (the loan and the borrower's name, never the message) can also reach its own Slack workspace. Mail filed to a loan record becomes part of that record, so an integration your organization connects receives it with the record, under your organization's instructions. Beyond these processors and integrations, and only to provide the features you use, Google user data is not transferred to any other app or third party; it is never sold and never used for advertising. If were ever part of a merger, acquisition or sale of assets, Google user data would be transferred only with your explicit prior consent, as Google's policy requires.

The providers we rely on today are listed below.

  • Google Cloud: hosting for our application servers, databases, file storage and secret storage, in data centers in the United States.
  • Anthropic: AI model provider (the default for language features).
  • Google (Gemini API): AI model failover, embeddings, speech-to-text and reading document layouts.
  • OpenAI: AI model provider for specific tasks where a per-task routing setting sends them there, under the same no-training restriction.
  • Google (Gmail, Drive, Calendar, Firebase, Fonts and address lookup): when you connect a Google account, sign in with Google, receive push notifications, load this site's typefaces or use an address field, your browser or our servers talk to Google.
  • Microsoft (Microsoft 365) or your own mail server: only if you connect such a mailbox instead of a Google account; the same rules apply.
  • Resend: email delivery for platform notices and for messages sent through this website's form.
  • Twilio: text-message delivery where your organization uses SMS.
  • Stripe: billing events and payment-method tokens for customers who pay by card.
  • Sentry: error reporting for the website and the platform.
  • Slack: only if your organization connects its own Slack workspace, and only the content it routes there.
  • Electronic signature runs on our own infrastructure (a self-hosted signing service), not on a third-party signing provider.
  • Optional integrations your organization chooses to connect, such as a CRM, property-data and property-listing lookup services, a bank-connection service, an address-validation service, a business-verification service or a voice-calling service, receive the data that integration needs, under your organization's instructions. They receive your organization's own records; mail filed to a loan record is part of that record. No integration is given access to your Google account.

Security

We protect information with technical and organizational safeguards appropriate to its sensitivity. Data is encrypted in transit, and our hosting provider encrypts stored data at rest; on top of that, connected-account tokens and integration credentials are encrypted a second time at the application layer with keys held in a managed secret store.

Every workspace is isolated to its customer, every request is checked against the signed-in person's role and permissions, and changes to records are written to an append-only audit trail. Secrets are never stored in code, and sensitive values such as passwords, tokens and government identifiers are removed from audit records and error reports before they are written.

No method of transmission or storage is perfectly secure. If we learn of a security breach affecting your information, we will notify affected people, our customers and the relevant authorities without undue delay and within the time the law requires. Where we process a customer's workspace content on its behalf, we notify that customer promptly so it can meet its own obligations to the people whose information it holds.

Data retention

Information you submit on this website is kept for as long as needed to respond to you and keep a record of our correspondence, then deleted when it is no longer needed. Page-visit counts hold no personal information.

Platform account information is kept for the life of your account and handled on closure as described in the section on closing a platform account.

Workspace content is retained for as long as the customer's subscription requires, then made available for export and deleted as described in the customer's agreement. Records that a lender must keep by law are retained for the period the law requires.

Google user data follows the periods set out in the section on how long we keep Google user data.

International transfers

is based in the United States and the platform is hosted there. If you use the service from outside the United States, your information is transferred to and processed in the United States, where data protection laws may differ from those in your country.

Where European, UK or Swiss law applies to a transfer, we rely on the European Commission's standard contractual clauses, the UK International Data Transfer Addendum, or another mechanism the law recognizes, and we require our service providers to do the same. You can ask us for a copy of the relevant safeguards at hello@fiops.ai.

Your rights and choices

You can ask us to access, correct, delete or export the personal information we hold about you by emailing hello@fiops.ai from the address on your account. We will verify your identity before acting. We respond within one month to requests made under European, UK or Swiss law and within 45 days to requests made under US state law; where the law allows, we may extend that period once, and we will tell you why. If we cannot act on a request, we will tell you the reason.

Where a self-service tool exists, you can use it directly: disconnecting a Google or other personal account and turning individual permissions off from your account settings, and, for borrowers, exporting your account data and clearing your Astor conversation history from the borrower portal.

If your information sits in a customer's workspace because that customer is your lender or employer, we will refer your request to that customer and help it respond, since the customer controls that content.

Rights for people in the EEA, the UK and Switzerland

You have the right to access your personal data, to have inaccurate data corrected, to have data erased, to restrict or object to its processing, to receive the data you provided in a portable format, and to withdraw consent at any time without affecting the lawfulness of processing before withdrawal. You also have the right to lodge a complaint with your local data protection authority.

To exercise these rights, email hello@fiops.ai. Where acts as a processor, we will pass your request to the customer that controls the data and support its response.

Rights for residents of California and other US states

If you live in California, Colorado, Connecticut, Virginia, Utah, Texas, Oregon or another US state with a consumer privacy law, you may have the right to know what personal information we collect, use and disclose; to access it and receive a copy; to correct it; to delete it; to opt out of its sale, of targeted advertising and of profiling that produces significant effects; to limit the use of sensitive personal information; and not to be discriminated against for exercising these rights.

We do not sell personal information and we do not share it for cross-context behavioral advertising, and we have not done either in the preceding twelve months, so there is nothing to opt out of. We use sensitive personal information only to provide the service you asked for.

To exercise these rights, email hello@fiops.ai. You may use an authorized agent, and we will verify the request before acting on it.

If we decline your request, you may appeal by replying to our decision with the word Appeal. We will respond to an appeal within 60 days and explain the outcome. If you are not satisfied, you may contact the attorney general of your state.

Some of these laws do not apply to information a lender holds under federal financial privacy law or to information about you in your role at a business. Where that is the case, we will tell you, and we will still help where we can.

Closing a platform account

A platform account belongs to the lender who created it for you, so cannot delete it on its own. You can ask for your account to be closed here, without opening the app, by emailing hello@fiops.ai from the address on the account.

Your request reaches both your lender’s administrator and , and either route lands in the same place. Your administrator has 30 days to act on it.

Closing an account deletes your profile, your personal details and your Astor conversations. Loan records and the audit trail are kept, because your lender is legally required to retain them. Disconnect any Google or other personal account you connected before you ask, as described under Revoking Google access, so its stored tokens are deleted at once.

Children

This website and the platform are for businesses and the adults who work with them. They are not directed at anyone under 18, and we do not knowingly collect personal information from anyone under 13. If you believe a child has provided us information, email hello@fiops.ai and we will delete it.

Changes to this policy

We update this policy when our practices change. The date at the top shows when it was last updated. If a change materially affects how we handle your information, we will tell you through the platform or by email before it takes effect.

Contact us

Fiops, Inc. is responsible for the personal information described in this policy where it acts as controller. Questions about this policy, or a request about your information? Email hello@fiops.ai and we will get back to you.