TL;DR
At Fidel API, a programme to extend the platform’s transaction data object beyond its standard 40-element payload identified a commercially material new revenue stream. The business case was built around a £0.50 per-transaction enrichment premium – a 25% markup over the existing six figures (£) revenue baseline across 1.3 million transactions. Carbon footprint scoring was designed and demonstrated as a proof-of-concept to prove the technical model was viable. The wider thesis – that joining live card transaction data with contextual third-party sources such as the Google Places API could unlock an entirely new category of transaction intelligence – was researched, architected, and presented to senior leadership. Phase 2, which would have operationalised this into a live product, was not approved.
CONTEXT
Fidel API sits within the card transaction value chain as a scheme-level data interceptor, giving developer clients real-time access to transaction data via Select Transactions API and Stream Transactions API. Its core differentiator is direct integration into card network infrastructure, enabling enriched JSON payloads to reach client applications at auth time – at the moment of the transaction, not after settlement.
By 2022, the standard transaction object was commercially undifferentiated. Clients processing transactions through the Fidel platform received the same data structure regardless of how they used it, with no mechanism to purchase richer contextual layers. The enrichment programme was conceived to change that: to test whether transaction data could become a tiered, premium product rather than a commodity API output.
PROBLEM
User problem
Fintech developers building consumer-facing financial products on Fidel’s APIs received a real-time transaction payload containing payment mechanics – amount, currency, MCC code, merchant name, geolocation – but no computed contextual layer. A cardholder completing a purchase received no information beyond the raw event: no sense of what kind of place they had visited, what the environmental impact of their spend was, or how that transaction related to their broader behaviour. The raw data was all present; the intelligence was absent. Clients who wanted to deliver contextual experiences had to build their own enrichment pipelines – a significant engineering overhead that increased platform churn risk.
Business problem
The revenue model was volume-dependent: every transaction through Fidel’s APIs generated the same unit economics regardless of its data richness. At a baseline of 1.3 million transactions generating six figures (£) in revenue, there was no pricing mechanism to capture the additional value Fidel could theoretically provide. Analysis indicated that a £0.50 enrichment premium per transaction would represent a 25% revenue uplift on enriched volumes – a secondary revenue stream requiring no new clients, only a new product tier. The business case was presented to senior leadership as a platform monetisation opportunity, not a new product line. However, the case did not progress to Phase 2 investment.
Technical / regulatory / operational problem
The core architectural constraint was Fidel’s real-time guarantee. Any enrichment computation had to complete within the auth window – sub-300ms from scheme interception to webhook delivery – without degrading existing transaction throughput. This ruled out enrichment types dependent on user transaction history (credit scoring, behavioural analytics, aggregated carbon tracking over time) and restricted the design space to stateless, single-transaction enrichment: operations completable against a single event payload with no historical read requirement. A secondary constraint was the data ownership model: different enrichment data sources carried different liability profiles for data accuracy, API uptime dependency, and cost-per-lookup that had to be resolved before any production build.
APPROACH
The programme was structured in two phases. Phase 1 ran to completion: it produced a validated technical architecture, a working proof-of-concept, and a commercial case for senior leadership. Phase 2 – productisation – was not approved.
Defining the enrichment opportunity space
The programme began by mapping what enrichment types were technically achievable within Fidel’s single-transaction constraint. Carbon footprint scoring was selected as the proof-of-concept not because it was the largest commercial opportunity, but because it was the simplest available demonstration: MCC codes present in every transaction could be joined to publicly available CO2/kg-per-USD datasets without requiring any user history. It was chosen to prove the GET→MATCH→COMPUTE→INJECT pipeline pattern, not to define the product’s ceiling.
The more commercially significant insight was what that same pipeline could enable when connected to richer third-party data sources. The Google Places API represented the most compelling of these: by using the merchant’s geolocation coordinates – present in every Fidel transaction object – to query Places API at auth time, a transaction could be enriched with structured data about the physical location of a purchase that the transaction payload itself could never contain.
The Places API exposes data fields including place type classifications, business operational status, price level, user ratings, review counts, opening hours, accessibility attributes, and editorial summaries. When fused with a live card transaction, these fields transform a raw payment event into a contextually rich data object. A transaction at a café becomes: independent coffee shop, price level moderate, rating 4.2, currently busy, outdoor seating available. A transaction at a petrol station near a motorway junction becomes: fuel purchase, EV charging available nearby, high-footfall location. Neither of these insights exists in the raw transaction payload – they emerge only from the join.
The programme identified four enrichment categories beyond carbon that this approach could support:
- Merchant intelligence – verified business type, rating, price tier, and operational attributes sourced from Places API place type taxonomy and Place Details fields, resolving the ambiguity of MCC codes (which describe industry category, not individual merchant character)
- Location context – neighbourhood classification, place density, transit accessibility, and proximity-based signals available from Places API Nearby Search
- Temporal and behavioural context – whether the transaction occurred during normal opening hours, during a busy period, or outside expected patterns – data derivable by joining transaction timestamp to Places API opening hours and popular times fields
- Environmental and sustainability signals – carbon scoring (the proof-of-concept use case) extended over time to include air quality at point of purchase via Google’s Air Quality API, and EV infrastructure proximity for transport-category transactions
This was the strategic argument presented to senior leadership: carbon enrichment was a proof-of-concept for a platform capability, not the capability itself. The real product was a configurable enrichment layer where clients could select which contextual data points they wanted appended to their transaction stream – each additional layer priced incrementally.
Architecture decision: three integration scenarios
Three integration models were evaluated to determine how Fidel would source enrichment data for production:
- Scenario 1 – Fidel owns the enrichment dataset, performs matching and computation. Maximum control and margin; maximum data acquisition cost and accuracy liability.
- Scenario 2 – A third-party partner owns the data; Fidel performs matching and computation. Lower data cost; Fidel retains computation control but inherits partner data quality risk.
- Scenario 3 – A third-party partner owns data and performs computation; Fidel ingests and delivers the enriched payload. Lowest build complexity; Fidel’s real-time SLA becomes dependent on partner latency.
For Google Places API integration specifically, Scenario 2 was the natural fit: Fidel would call the Places API per transaction using the geolocation fields already present in the transaction object, perform any required computation internally, and inject the enriched fields into the TXN object before webhook delivery.
Commercial case to senior leadership
The business case was framed around the existing client base: no new sales motion required, no new infrastructure category, no regulatory exposure. An enriched transaction tier would be made available as an opt-in product to existing Stream Transactions API and Select Transactions API clients – billed at a £0.50 premium per enriched transaction. At even 20% adoption across the existing 1.3 million monthly transaction volume, the model projected circa £130,000 in incremental monthly revenue. The case was presented to senior management; Phase 2 was not approved.
ARCHITECTURE
Transaction Enrichment – Extended Data Model
This diagram shows how the Fidel transaction object’s existing geolocation and MCC fields become join keys into external enrichment sources – carbon data, Google Places API, and environmental APIs – to produce a contextually enriched output payload.
It was designed this way to make the enrichment layer additive and backward-compatible: all existing transaction fields remain unchanged, and enrichment fields are appended as a new node in the JSON object. This meant existing client integrations required no modification to benefit from enrichment – adoption could be configured at the API subscription level rather than requiring client-side engineering changes.
The constraint driving this design was client integration risk: breaking changes to the existing TXN object schema would have required coordinated engineering work across every active Fidel client. Additive enrichment eliminated that dependency entirely.
Carbon Enrichment Proof-of-Concept – Transaction Flow
This diagram shows the validated end-to-end flow from card scheme interception through to enriched webhook delivery, demonstrating that the GET→MATCH→COMPUTE→INJECT pattern was technically executable within Fidel’s real-time processing loop.
The enrichment service was positioned inside Fidel’s auth-time processing window rather than as a post-settlement batch job because Fidel’s core value proposition – delivery at the moment of the transaction – had to be preserved. Post-settlement enrichment would have destroyed the differentiator and removed any basis for the premium pricing model.
The constraint was 300ms end-to-end latency, validated in the proof-of-concept build.
Enrichment Integration Scenarios – Architecture Decision
This diagram shows the three data ownership and computation models evaluated, each with different implications for build cost, accuracy liability, and real-time SLA risk. For Google Places API enrichment specifically, Scenario 2 was identified as the production architecture: Fidel calls Places API per transaction using the geolocation join key, computes contextual fields internally, and injects them into the TXN object.
OUTCOMES
What was validated
- Carbon enrichment proof-of-concept delivered end-to-end: scheme interception → MCC lookup → CO2 computation → enriched webhook, within the sub-300ms latency target
- The GET→MATCH→COMPUTE→INJECT pipeline was proven as a reusable enrichment pattern applicable to any stateless, single-transaction data source
- Google Places API was identified and documented as the highest-value enrichment data source: the geolocation fields present in every Fidel transaction object serve as a direct join key to place type, rating, price level, operational status, temporal context, and environmental data – none of which exists in the raw payment payload
- Four enrichment categories were prioritised and sequenced: carbon footprint, merchant intelligence via Places API, environmental context (air quality, EV proximity), and temporal behavioural signals
- The commercial case was modelled and presented to senior leadership: a £0.50 per-transaction enrichment premium on 20% of existing volume projected circa £130,000 in incremental monthly revenue – a 25% uplift over the existing baseline – requiring no new client acquisition
- Phase 2 was not approved
What was learned
The programme revealed that the constraint shaping the product was not technical – the proof-of-concept validated the pipeline clearly – but organisational. The case for a secondary revenue stream required senior leadership to accept that Fidel’s core API business could support a premium tier without cannibalising developer adoption. That framing, rather than the architecture, was the harder problem. In hindsight, anchoring the commercial case to a specific client pilot commitment rather than a revenue projection model might have been a more persuasive path to Phase 2 approval.