Fintropy
Feature Reference
Every capability explained in plain language — what it does, how it works, and why it matters for your cloud budget.
Cloud Waste Detection
Fintropy runs 199+ deterministic scan rules against your cloud environment. Unlike AI-driven suggestions that can vary between runs, every rule is a fixed algorithm that produces the same result every time — making findings auditable, reproducible, and defensible to finance teams.
What gets scanned
(EC2, VMs, GCE)
(S3, Blobs, GCS)
(RDS, SQL, BigQuery)
(EIPs, Load Balancers)
(Lambda, AKS, GKE)
(IAM, tagging, encryption)
Categories of waste detected
🖥️ Idle & oversized compute
Instances with CPU utilisation <5% over 14 days, memory headroom >70%, or GPU instances with near-zero GPU utilisation. Fintropy identifies the right-size recommendation based on observed peak load, not just average — preventing over-correction.
💾 Orphaned storage & snapshots
Unattached EBS volumes, Azure managed disks not connected to any running VM, GCS buckets with zero reads in 90 days, and snapshots older than your configurable retention policy. Also detects S3 buckets with data but no lifecycle policy — a silent cost that grows monthly.
🌐 Network waste
Elastic IP addresses not attached to a running instance, idle Application Load Balancers (no healthy targets), NAT Gateways processing less than 1 GB/day, and Azure Public IP addresses allocated but unassociated. Cross-region data transfer routes are also flagged where cheaper alternatives exist.
🎟️ Reserved Instance & Savings Plan gaps
On-demand instances running workloads that match the profile of an available RI or Savings Plan commitment you haven't purchased. Fintropy shows the 1-year and 3-year breakeven and estimated annual saving with a confidence score based on instance stability.
🗄️ Over-provisioned databases
RDS/Aurora instances where storage auto-scaling headroom exceeds 300%, read replicas with zero query traffic in 7 days, and multi-AZ deployments for non-production workloads that can safely tolerate single-AZ failure.
Tier classification
Rules are classified as Tier 1 (deterministic) for financial auditing — the finding amount is exact and reproducible from billing data. A second Tier 2 (AI-assisted) tier uses Gemini to surface pattern-based optimisations (e.g. workload scheduling, architecture anti-patterns) where exact savings can't be pre-calculated.
Each recommendation includes
- Estimated monthly saving ($)
- Effort score (Low / Med / High)
- Affected resource ID and region
- Specific remediation action
- Supporting evidence (metrics)
- Rule ID for audit trail
- Risk assessment
- One-click or scheduled fix
Automated SLA Breach Claims
Every major cloud provider publishes SLA commitments for uptime — typically 99.9% to 99.99% per service. When they miss those targets, you're entitled to service credits. The problem: you must file a claim with documented evidence within a strict window. Most teams never bother. Fintropy does it for you automatically.
Why this matters
A company spending $500k/month on AWS with a major us-east-1 outage lasting 45 minutes could be entitled to 10–25% monthly credit for affected services — potentially $20,000–$50,000. Without an automated system monitoring and filing, that credit expires unclaimed.
How the claim pipeline works
Continuous availability monitoring
Fintropy monitors resource health, availability zones, and provider status pages in real time. Probe intervals are configurable down to 30 seconds for critical resources. All health check results are timestamped and stored immutably for evidence.
SLA threshold correlation
When downtime is detected, the engine compares it against the applicable SLA tier for your account (Standard, Enterprise, etc.) and the specific service. Provider SLA documents are kept up to date in Fintropy's rule database — no manual tracking required.
Evidence package assembly
Fintropy assembles a structured evidence package containing: downtime start/end timestamps, error logs, health-check failure records, affected resource IDs, and the provider's own incident report where available. The package meets each provider's specific claim format.
Claim filing & tracking
The claim is filed via the provider's support API or portal (with your authorisation). Fintropy tracks the claim lifecycle — submitted, under review, approved, credited — and matches approved credits against your billing statement to confirm receipt.
Credit reconciliation
Approved credits are matched to your monthly billing records. Fintropy tracks total credits recovered year-to-date — giving your CFO a clear dollar figure on money that would otherwise have been lost.
Covered providers & services
Real-Time Anomaly Detection
Cost spikes don't wait until the end of the month. Fintropy runs z-score analysis over 28-day rolling baselines for every service across every connected account — surfacing unexpected spend within hours, not weeks.
How the z-score model works
For each service (e.g. EC2 in us-east-1, Azure Blob Storage), Fintropy maintains a 28-day rolling window of daily spend. When a new day's spend arrives, it calculates how many standard deviations it sits above the mean baseline.
Per-service granularity
Anomalies are detected at the service level within each cloud account — not just at the total-account level. This means a spike in Lambda costs caused by a runaway function is surfaced immediately, even if it's only 2% of total EC2 spend.
Deduplication logic
Multiple anomalies for the same service on the same day are deduplicated — you receive one alert per service per day, upgraded to CRITICAL if the z-score crosses the higher threshold during the day. This prevents alert fatigue.
What an anomaly alert contains
- Service name and cloud account
- Today's spend vs. 28-day average
- Z-score and severity level
- Delta percentage vs. baseline
- Timestamp and region
- Link to affected resources
- Suggested investigation path
- Acknowledge / dismiss action
Common causes surfaced by anomaly detection
Forgotten load test environments left running · Runaway Lambda functions in infinite loops · Data pipeline misconfiguration writing to expensive storage class · New dev environment deployed without a shutdown schedule · Third-party integration billing unexpectedly at full production rate
Budget Management
Set spending limits by team, project, cloud account, or service. Track actuals against forecast in real time. Get alerted before budgets are breached — not after the invoice arrives.
Flexible budget scopes
Budgets can be applied at the organisation level, per cloud account, per team, or per cost tag value. A single Fintropy workspace can manage dozens of parallel budgets with no performance impact.
Alert thresholds
Each budget supports up to 5 configurable alert thresholds — e.g. warn at 70%, 85%, and 100% of limit. Alerts are delivered in-app, via email, and optionally to a Slack webhook. Threshold percentages are fully customisable per budget.
Forecast-aware tracking
Fintropy projects end-of-period spend based on current daily run rate. If you're 18 days into a 30-day period and burn rate indicates you'll exceed budget, you're alerted with enough time to act — not just informed after the fact.
Budget status at a glance
Every budget shows one of three states: On Track (forecast < 90% of limit), At Risk (forecast 90–100%), or Over Budget (actuals exceed limit). The dashboard surfaces At Risk and Over Budget items first.
Typical workflow
Finance sets a quarterly cloud budget in Fintropy → Engineering teams see their allocated portion and current burn → Fintropy alerts the team lead when forecast exceeds 85% → Team reviews anomalies and waste recommendations → Month closes under budget.
Spend Analysis
A unified view of every dollar spent across AWS, Azure, and GCP — broken down by service, region, team, tag, and time period. No more exporting CSVs from three different billing consoles.
Multi-cloud cost aggregation
All billing data is ingested from AWS Cost Explorer, Azure Cost Management, and GCP Billing Export. It's normalised to FOCUS 1.2 format so line items are comparable across providers — a "Compute instance hour" means the same thing whether it came from AWS or GCP.
Trend analysis & forecasting
Month-over-month and quarter-over-quarter cost trends per service and account. Linear regression forecasting projects end-of-month and end-of-quarter totals based on current daily run rate, updated every 24 hours as new billing data arrives.
Tag-based cost allocation
Filter and group spend by any tag key/value pair — Environment, Team, Project, CostCentre. Fintropy flags resources missing required tags so cost allocation remains complete and accurate across the organisation.
Availability & Uptime Monitoring
The data source that powers SLA breach claims. Fintropy monitors your cloud resources continuously, stores health events immutably, and calculates monthly uptime percentages per service against provider SLA thresholds.
What is monitored
API response codes from cloud management endpoints, resource health status from AWS Health, Azure Resource Health, and GCP Service Health APIs, plus custom HTTP probes you can configure for application-level availability checks.
Immutable event log
Every health-check result — success or failure — is stored with a microsecond-precision timestamp. This log is the primary evidence source for SLA claims. It cannot be edited or deleted after write — ensuring integrity for any dispute.
Monthly uptime reports
Automated monthly PDF reports showing uptime percentage per resource, compared against the applicable SLA. Reports are shareable with your finance team and saved for 24 months so historical claims can still be substantiated.
Compliance & Governance
FinOps isn't just cost — it's discipline. Fintropy enforces tagging policies, flags security misconfigurations that increase cost risk, and ensures your cloud environment stays aligned with internal governance standards.
Tagging compliance
Define required tag keys (e.g. Environment, Owner, CostCentre) and Fintropy continuously audits all resources against your policy. Non-compliant resources appear in a dedicated Governance view. Bulk-tagging actions are available for quick remediation.
Security cost risk flags
Publicly accessible S3 buckets, unencrypted RDS instances, and overly permissive IAM roles don't just create security risk — they create cost risk (e.g. egress charges from data exfiltration). Fintropy flags these at the intersection of cost and security.
Policy enforcement rules
Define custom policies — e.g. "no instance type larger than m5.xlarge in Development", "all S3 buckets must have lifecycle rules", "no resources in regions outside EU". Policy violations are surfaced as findings with the same priority and evidence as cost rules.
Approval Workflows
Remediation actions in production need oversight. Fintropy's built-in approval workflow ensures the right people sign off before any change is executed — without slowing down the process with manual Slack threads.
Multi-step approvals
Configure approval chains by action type and risk level. Deleting a snapshot in dev might require only engineer sign-off. Resizing a production database requires engineer + team lead + on-call SRE. Each step is time-stamped and logged permanently.
Approval request notifications
Approvers receive in-app notifications and email with the full context of the request: resource ID, proposed change, estimated saving, risk assessment, and a one-click approve/reject link that works from mobile.
Audit trail
Every approval decision is stored with the approver identity, timestamp, and any comment added. Audit logs are exportable to CSV or JSON for compliance reporting. Rejected actions and their reasons are preserved permanently.
Remediation Actions
Fintropy doesn't just identify problems — it fixes them. After approval, the platform executes safe, targeted cloud operations across AWS, Azure, and GCP using read-write credentials scoped to minimum required permissions.
Available automated actions
Scheduled actions
Rather than taking an immediate action, schedule it for a low-traffic window — e.g. "Stop all dev instances every weeknight at 20:00 UTC, restart at 08:00". Schedules are defined per resource or resource group and are fully reversible.
Rollback & safety controls
Destructive actions (snapshot deletion, instance termination) require a secondary confirmation and have a configurable cooling-off period during which they can be cancelled. Non-destructive actions (right-sizing, scheduling) can be immediately rolled back from the Fintropy dashboard.
Multi-Cloud Connection
Connect your AWS, Azure, and GCP environments in minutes using standard, read-only mechanisms. No agents, no SDKs to install, no code changes to your applications.
AWS — CloudFormation stack
A one-click CloudFormation template creates a cross-account IAM role with a locked-down permissions set (Cost Explorer read, EC2 describe, S3 list, RDS describe, CloudWatch metrics). External ID rotation prevents confused-deputy attacks. The role is scoped to the minimum permissions Fintropy needs — nothing more.
Azure — Lighthouse delegation
The customer grants admin consent for Fintropy's multi-tenant app registration, then deploys a Lighthouse ARM template that delegates subscription-level access to Fintropy's managing tenant. Fintropy's service principals are assigned Reader and Cost Management Reader roles — read-only by design. No service principal secrets are stored in your tenant.
GCP — Workload Identity Federation
A GCP service account is created in your project with roles/billing.viewer and roles/compute.viewer. Fintropy authenticates via Workload Identity Federation — no long-lived service account JSON key is generated or stored. Access is revoked instantly by deleting the service account.
Security first
All cloud credentials are stored in HashiCorp Vault with automatic rotation. Connections are established over TLS 1.3. Each connection has its own isolated credential path — a compromise of one account cannot affect others. Connection status is monitored continuously and you're alerted if access is revoked or expires.
FOCUS 1.2 Billing Standard
Fintropy normalises all billing data to the FinOps Open Cost and Usage Specification (FOCUS) 1.2 — the industry open standard developed by the FinOps Foundation. This means a compute instance hour from AWS, Azure, and GCP is represented identically, enabling true apples-to-apples comparison.
Why FOCUS 1.2 matters
Each cloud provider bills in a different format: AWS CUR has 300+ columns, Azure's billing API uses different terminology, and GCP exports to BigQuery with its own schema. Without normalisation, comparing "storage cost" across clouds is comparing different things. FOCUS 1.2 defines 37 standard columns that every provider's data maps to.
Fintropy's FOCUS implementation
Billing records are ingested nightly, transformed into the FOCUS 1.2 schema, validated
against the spec, and stored in the focus_billing_records
table. Your data warehouse team can export this table as-is — no further transformation needed.
Team Management
Fintropy is built for teams, not individuals. Role-based access control, email invitations, and multi-tenant isolation ensure that the right people see the right data — and nothing more.
Roles
Admin — full access including billing, team management, and connection setup. Engineer — can view findings, approve actions within their scope, and manage resources. Viewer — read-only access to dashboards and reports, no action permissions. Roles are assignable per member and can be changed at any time.
Email invitations
Admins invite new members by email. Invitation tokens expire after 7 days and are single-use. If a member is re-invited, the previous token is automatically revoked. Accepted invitations create a new Fintropy account automatically linked to the tenant.
Multi-tenant isolation
Every customer's data lives in an isolated tenant namespace enforced by Row-Level Security at the PostgreSQL layer. No application-layer filtering is relied upon for data separation — the database engine enforces it, making cross-tenant data leakage architecturally impossible.
Alerts & Notifications
The right person gets the right alert at the right time — without noise that trains teams to ignore notifications.
In-app notification centre
A bell icon in the dashboard header shows real-time unread count. Clicking reveals a sorted feed of: budget threshold breaches, anomaly detections, SLA events, pending approval requests, and system messages. Each notification links directly to the affected item. Mark individual items or all as read.
Email delivery
Critical alerts (budget over limit, CRITICAL anomaly, SLA breach confirmed) trigger immediate email to the team's configured alert addresses. Daily and weekly digest options are available for summary reporting without interrupting workflows.
Slack webhook integration
Point Fintropy at your Slack channel's incoming webhook and it will post structured messages for each alert type. Alert messages include the key metric, severity, and a deep link back to Fintropy for full context.
Alert suppression in demo mode
When exploring Fintropy using demo data, the notification bell is hidden and no external alerts fire — ensuring that demo walkthroughs don't spam your team's Slack or email inboxes.
Ready to try Fintropy?
Our team will complete your first multi-cloud scan within 48 hours of signup — no commitment required.