Trust & Security

Inside your own environment. What we build is a custom application deployed into your cloud subscription — your container, your database, your private network endpoints, your storage. Fintask does not host it and does not hold a copy of it.

This is the difference between hiring a builder and subscribing to a product. There is no Fintask multi-tenant platform that your ledger data passes through, because there is no Fintask platform. When the engagement ends, the system is still yours, still running, in the same place it always was.

You create a named user account for us in your own directory — Entra ID in most engagements — exactly as you would for an employee or contractor. We work from inside that account.

No shared logins. No credentials sent over email. No service principal or API key held on Fintask infrastructure outside your tenant. Whatever your organisation enforces on its own staff — multi-factor authentication, conditional access, device compliance, IP restrictions, session limits — applies to us automatically, because we are subject to the same policies as any other account in your directory.

Yes, in your own logs, without asking us. Sign-ins appear in your Entra ID logs. Deployments and resource changes appear in your Azure activity log. Code changes appear in your repository history.

This matters more than it sounds. With a typical software vendor, the assurance you get about their behaviour is a document they wrote about themselves. Here, the record lives in systems your team already operates and already trusts. You do not have to take our word for anything.

You disable the account. It takes under a minute, you do it yourself in your own admin console, and you do not need to contact us, rely on a contractual promise, or trust that a deletion request was honoured.

On a planned handover we also run a written offboarding: any secrets we touched are rotated, our account is removed, any local working copies are destroyed, and we confirm the whole list back to you in writing so you have a record for your own files.

Not in normal operation. The systems we build read from your data and write back to your data, in your environment. Where a document or workbook has to be processed, it is processed in place and the working copy is deleted when the job closes — what is kept is the result and a fingerprint of the file, which is enough to prove later which version was processed without holding the contents anywhere.

Development work is done against your environment. Where something has to be tested outside it, we use anonymised or synthetic data, not live records.

Read-only by default. Your ERP stays the system of record and the application keeps its own working data separately. Nothing is written back to the ledger unless that write is explicitly scoped, agreed and built for — and where it exists, it goes through the approval and reconciliation gates described below rather than posting automatically.

Where a build uses a language model, the relevant content — an invoice, a workbook extract, a customer record — is sent to the model provider for the duration of that call and the answer comes back. That is the only point at which anything leaves your environment, and it is governed by the terms in the next two answers.

Where an engagement requires that nothing leaves your environment at all, the model is deployed inside your own cloud subscription instead (Azure AI Foundry or Azure OpenAI in your tenant), so the call never crosses your network boundary. If that is a requirement for you, say so at the start and the build is designed around it.

No. Model access runs on commercial API terms, which exclude customer content from training. Consumer chatbot terms — the ones that do allow training — are not used for client work and never have been.

More to the point, the model account is yours, not ours. The build calls the provider using your own commercial account and your own API key, held in your vault inside your environment. So the terms governing your content are terms you hold directly with the provider rather than terms you inherit from a middleman — and where you hold an enterprise agreement with zero data retention, it applies automatically, because it is your account making the call.

This is the same principle as the rest of the engagement. We do not sit between you and your vendors. Your cloud subscription is yours, your model account is yours, and the commercial and privacy terms attached to both stay under your control.

No, and this is engineered rather than hoped for. Every number a Fintask system reports is grounded in your source data. Where arithmetic is involved, the system computes it in code that it writes and runs, and the code and its output are attached to the result — so any figure can be traced back to the calculation and the source cell that produced it.

It is the difference between a system that estimates an answer and one that works it out and shows you the working. Ours shows the working, and a reviewer can check it.

Four things, in every build. Customer-facing communications go through a human approval queue before anything is sent. Extraction results pass mathematical reconciliation gates before they reach the ERP. Legal, disputed and sensitive cases hard-stop to a human rather than being handled automatically. And anything the system flags is a proposal — accepting it stays a deliberate click by one of your people.

The AI does the reading, drafting and matching. Your team keeps the decisions.

Hard spend ceilings enforced in code, per run and per day, with the job stopping rather than overrunning. Model costs are metered against your own account so you can see the spend directly rather than being billed for it opaquely.

Anthropic (Claude) and OpenAI, depending on the build — accessed through your own commercial account with them, or deployed inside your own Azure subscription. They are named in the subprocessor list below, and the list for your engagement is confirmed in writing before anything is built.

No, and for the way we work it would tell you very little. SOC 2 is a report on a service provider's own environment — where your data is received, processed and stored. It exists for the software-as-a-service model, where your data leaves your organisation and lands in the vendor's cloud.

That is not what happens here. Your data does not leave your organisation and there is no Fintask cloud for it to land in. A SOC 2 report on Fintask would attest to a scope that contains almost none of the risk you actually care about, at a cost that would be passed on to you.

The controls that genuinely matter in this model are the ones governing our access to your environment — and those are controls you already operate, already enforce and can already audit yourself. Where a specific engagement is gated on formal certification, that can be discussed and arranged as part of scoping.

Least privilege on a named account in your directory, under your own access policies. No shared or standing credentials. Change control through your repository with reviewable history. Secrets held in a managed vault in your environment, never in code or configuration files. Written offboarding with secret rotation on handover. Anonymised data for anything tested outside your environment. Encryption in transit and at rest, provided by your own cloud platform rather than by us.

These are the substantive parts of an ISO 27001 control set applied at the scale this work actually operates at. We will walk through them line by line in a review call, and we will complete your security questionnaire.

Reza Shahrokhi ACA — a Chartered Accountant who builds the systems personally. That matters for two reasons a security reviewer will care about. There is no rotating bench of subcontractors with access to your finance systems; access is one named individual you can identify. And a chartered accountant answers to a professional body with a disciplinary process, which is a form of accountability most software vendors cannot offer at all.

It also means the person reading your ledger understands what is in it. Financial data is not treated as an abstract payload here.

This is a fair question and the answer is unusually good, because of where the work lives. The application runs in your tenant. The code is in your repository. The data is in your database. The documentation is handed over as part of delivery. None of it depends on Fintask continuing to exist.

Worst case, you engage another developer and they pick up a running system with its source code. Compare that with a software vendor going under, which takes the product, the data and the integration with it.

Yes. Accessing personal data on your behalf is processing, even though we do not store it, so a data processing agreement applies and we sign one for every engagement. The practical scope is narrower than usual — the agreement covers access to data in your systems rather than transfer of data into ours, and the subprocessor list is correspondingly short.

Yes, all three, and we would rather work under your paper than ours. Our own terms and privacy policy are linked at the foot of this page, but neither is a condition of working together — if your legal team has a preferred set of documents, send them and we will work from those.

Fintask is based in Ireland and operates in the EU. Your data sits in whichever region your own cloud subscription is configured for — we deploy into your environment, so your data residency decisions carry over unchanged and there is no cross-border transfer to assess.

Yes, and quickly. Most of it answers itself in this model — a large share of any standard questionnaire asks what happens to data once it leaves your building, which for these engagements is largely not applicable. Send it over and it comes back completed, with the not-applicable answers explained rather than left blank.