Investicus.eu

For Claim Admins

Claim Admin guide

The moment you're assigned to a claim, you can see every participant's real name, email, investment amount, and transaction reference. This guide explains what that responsibility actually means — it isn't tribal knowledge you're expected to already have.

You are handling other people's personal and financial data

As a Claim Admin, you can see the full roster for your claim: names, emails, amounts, transaction references, and any instrument/loan reference participants entered. Treat this the way you'd want your own financial details treated. Concretely: only use this data to coordinate the claim and to hand it to the assigned lawyer for the group. Don't forward the CSV or JSON export, or copy roster details into a separate spreadsheet or messaging app, for any other purpose. Don't share it with anyone outside the claim's own legal process. If your role on a claim ends, or the claim resolves, delete any exported copies you made rather than keeping them indefinitely. Every roster view and export you make is logged (visible to Global Admins only, not to you) — this exists to protect participants if a Claim Admin account is ever compromised or misused, not to monitor routine, legitimate use of your own claim.

What "verified" means here

Investicus.eu deliberately never stores ID documents, bank statements, or other proof files — see our Terms of Service. So "verifying" a signup isn't a technical checkbox in this app; it's a judgment call you and the assigned lawyer make together, usually by cross-referencing a participant's transaction reference or instrument/loan reference against the platform's own investor records, once you have them. Until that cross-referencing happens, treat every signup as an unverified self-report — accurate for aggregate counts and totals, but not yet something you'd stake a legal filing on. That's exactly why document verification for the actual case happens offline, directly between participants and the assigned lawyer, not through this app.

Writing a good timeline update

Every update you post is public and permanent — there's no edit or delete once it's posted, so read it back before submitting. Beyond the neutral-wording guideline already shown on the update form, a good update: – States what actually happened and when, not a vague reassurance ("We heard back from the platform's administrator on 14 July; they confirmed the insolvency filing date." beats "Still working on it.") – Says what happens next, if you know it, so participants know whether to expect another update soon – Flags a deadline explicitly if one is set and approaching, rather than assuming participants are checking the countdown themselves – Doesn't just repeat numbers already visible on the page (investor count, total loss, status badge) — those update automatically; use the update itself for what changed