Technical & Integration Requirements
5.1 Data Quality & Granularity
What We Expect:
Rich transaction metadata: Merchant names, MCC/category codes, timestamps, references, and descriptions.
Standardised formats: Clean, well-documented transaction schemas across all supported banks.
Historical data access: Minimum 12 months of transaction history for trend and budgeting analysis.
Why It Matters:
Accurate SFS mapping depends on high-quality, structured transaction data, particularly for categories like:
Housing & utilities
Transport
Food & housekeeping
Subscriptions and financial commitments
Response
Raw data is parsed, cleansed and normalised into a standardised format that can be consumed via API by Paylink and its end clients. The key stages of this process are outlined below:
Data Validation - All incoming data is validated and standardised. Each data field is checked for consistency and verified against expected formats, such as field types and enumerations (Enums).
Data Normalisation - all duplicates within raw transactional data are identified and removed.
Data Standardisation - We pride ourselves on our ability to present data aggregated across different providers in a coherent, standardised format. To achieve this, we apply our own transaction format, which includes all the necessary elements to sufficiently describe and provide context for each transaction. In addition, data in its raw state—post validation and normalisation—is made available for our clients to consume.
Data enrichments - categorisation, merchant id, recurring payments, flags and insights, etc...
Enrichment Coverage - The threshold is the value at which we assign the predicted category to a transaction, based on the confidence level returned by the model. All category predictions that fall below the threshold are assigned to a 'general' category. Typically, we categorise 95% of transactions, with the remaining 5% tagged as 'general'.
Enrichment Accuracy - Our current model achieves the below accuracy rates across each of the categorisation levels applied:
Level 1 - 98.5%
Level 2 - 97.2%
Level 3 - 97%
5.2 Transaction Categorisation & Enrichment
Must Support:
Native transaction categorisation
Ability to apply custom categorisation models (rule-based or machine learning)
Merchant enrichment and transaction classification
Evaluation Criteria:
Can the provider differentiate between business vs. personal, and recurring vs. one-off payments?
Support for custom tags/labels to align with SFS categories
Flexibility in applying post-processing logic to enrich or override default categories
Our enrichment models use natural language processing (NLP). These proprietary categorisation models have been refined over the past nine years and trained on hundreds of millions of transactions to achieve the highest levels of accuracy. Our categorisation achieves over 98% accuracy. The model trains on multiple features of the data, including description, amount, and proprietary codes.
We have found that using neural networks enables us to handle non-linearity and edge cases, thereby increasing the granularity of categorisation to a set of over 200 low-level tags. Our model is designed to be flexible, allowing us to easily add new low-level categories or adjust the taxonomy hierarchy to accommodate emerging use cases.
Additional information regarding mapping, re-mapping, and SFS buckets is provided in previous responses. Similarly, our taxonomy considers both personal and business transactions and can be configured (mapped) accordingly.
Merchant enrichment - Our merchant-trained AI model works by identifying which substring of text in a transaction description represents the merchant entity. This is then matched to our merchant database to retrieve additional details such as the full name, logo, and more. We continuously update the merchant database with new data, for example, when the model encounters new entities, and we can easily tailor the service to reflect client preferences. We provide an industry-leading match rate of approximately 80% for merchants, along with the added capability to deliver relevant merchant logos and around 96% coverage for processors (e.g., PayPal, Square, iZettle, etc.).
Recurring payment enrichment - Our data enrichment service detects any transaction that recurs on a daily, weekly, bi-weekly, monthly, or quarterly basis. This includes Direct Debits, Standing Orders, regular credit card subscriptions, and recurring transfers. The service identifies both incoming and outgoing transactions.
Additionally, our platform supports re-categorisation and merchant re-labelling based on individual client or customer preferences, as well as bulk or batch re-categorisation.
5.3 API Design & Developer Experience
Core Requirements:
RESTful APIs with consistent schemas across institutions
Well-documented endpoints with examples and guides
Webhooks for reauthentication events, transaction updates, and user events
Secure and stable sandbox/test environment
Bank statements in PDF and on-demand access to retrieve it via API
Preferred Enhancements:
Software Development Kit (SDK) or client libraries
Developer dashboard with:
API usage tracking
Bank connections
Consent management tools
All of our platform services can be consumed via API and surfaced within any mobile or desktop solution. Our suite of RESTful APIs consists of request and response payloads formatted in JSON, allowing integration using any programming language. This makes it straightforward to embed our services seamlessly into a client’s chosen technology stack.
Clients are provided with access to the relevant instance environment through the creation of a unique set of credentials. These API credentials enable secure access to the services within the environment via OAuth2 authentication.
To maintain the highest possible performance, we employ asynchronous tasks such as data ingestion and data refreshes. In addition, we have implemented a number of webhooks that can be configured by clients to stream real-time status updates on customer transactions or enrichment tasks.
We offer a fully-fledged sandbox environment that clients can register for via our developer console. Access is granted through a short application form, after which clients are enrolled into the sandbox, allowing them to activate their account, create application credentials, and begin integrating and testing against the sandbox environment.
Our sandbox mirrors the production environment, with updates made in tandem. The only difference is in Open Banking connectivity—within the sandbox, clients can only connect to the sandbox environments of various providers and interact with dummy data. Please note that some rate limits do apply within the sandbox.
API Docs: https://docs.thisisbud.com/
Dev Console: https://console.thisisbud.com/
Dev Guides: https://docs.thisisbud.com/docs/console-get-started
Enhancements:
In response to Paylink’s request, and as part of this proposal, we will configure the API to enable seamless access to PDF bank statements through a simple integration. This enhancement will provide Paylink’s clients with a more streamlined and user-friendly way to retrieve bank statements, improving both efficiency and overall experience. TransUnion will work closely with Paylink to confirm the requirements and develop a solution aligned with expectations.
We offer several web-hosted journeys and widgets for easy integration.
Our developer dashboard includes some business metrics; please note that other management information (MI) is typically provided on a periodic basis.
Consent, connections, and client activation are managed as standard via the console or API.
5.4 Consent, Security & Compliance
Must-Have Features:
FCA-authorised AISP status
OAuth 2.0-based consent and secure token exchange
GDPR-compliant data handling (incl. user data deletion)
Short- and long-term token lifecycle support for session management
TransUnion is ISO27001 certified, Cyber Essentials Plus certified and fully FCA regulated and licensed. Paylink can be assured we can fulfil requirements, and as data is fundamental to our business, we have robust security processes, so data is always secure.
TransUnion ensures GDPR-compliant data handling through a lawful basis of processing (legitimate interest for fraud prevention), detailed privacy notices, and rigorous Data Protection Impact Assessments. User data deletion and subject rights are addressed in line with GDPR, and all staff undergo mandatory annual data protection training.
In terms of token lifecycle, our API follows the standard OAuth2 protocol. Upon enrolment via the Console, Paylink will be provided with a client ID and client secret, which can be used to obtain access and refresh tokens. The access token must be supplied as a Bearer token in every subsequent API call. Once the access token expires, the refresh token must be used to obtain a new access token
5.5 Bank Coverage & Uptime
Key Questions:
Number of supported banks & account types (UK consumer and business accounts, joint accounts)
Connection success rate and frequency of updates
Real-time status dashboard or uptime metrics
TransUnion boasts 96%+ account connection coverage via Open Banking and where possible includes all supported account types (current, credit cards, savings, business). Please see the included table for an up-to-date coverage detail: https://docs.thisisbud.com/docs/connect-coverage-table
Our API services include built-in timeout and retry logic as standard. Additionally, banks can be placed into “maintenance mode” when unavailable—either manually or automatically. For scheduled downtime, banks notify TSPs so that maintenance plans can be added to the platform and handled manually. In cases of unexpected failures, fail-safe mechanisms automatically place the bank into maintenance mode and initiate background testing until the issue is resolved.
Our platform now processes over 5 billion transactions annually and is regularly tested to handle transaction rates of up to 33,600 per second. It has maintained an API connection success rate of over 99.999% with Enterprise Platform clients since launch. Across the entire customer base, including SMEs and fintechs, all clients have experienced at least 99.99% uptime over any rolling 12-month period in the past four years. Today, the platform processes between 25 to 100 million transactions daily on average. A range of uptime SLA packages is attached for your reference.
Updates are managed internally and always support backward compatibility. A robust promotions procedure ensures that all application containers are built before any promotion occurs. Only after all automated tests have successfully passed will any merge or promotion proceed. In the unlikely event of an unforeseen error following a promotion, both automated and manual rollback capabilities are in place to minimise service disruption. Live products are supported by comprehensive monitoring and alerting systems. Machine learning models are continuously tested and improved, learning from new data over time. Software updates are made regularly, typically every other day.
We also provide a service availability status page that informs clients of any known issues or incidents with the platform. Clients can subscribe to updates via email, text, webhook, or Atom/RSS feed. Internally, various telemetry and business metrics are continuously reviewed to monitor and maintain service levels. This management information, along with other performance metrics, is typically shared with clients through monthly reports.
5.6 Integration with SFS Mapping Logic
Ability to tag or classify transactions into SFS-relevant categories (rent, food, fuel, etc.)
Easy mapping to our internal SFS taxonomy
Ability to define custom rules for:
Frequency (e.g., monthly recurring)
Merchant name recognition
Amount thresholds
As mentioned in the Core Functional Requirements section, Bud is an active member of the SFS and adheres to its code of conduct and best practice principles, which are reflected in its Assess platform. The platform features a flexible and granular transaction categorisation model, tagging each transaction with up to three category tiers supporting over 200 tags to align with SFS buckets and client-specific taxonomies. The platform also enables mapping customisation, allowing clients to remap categories to suit their unique needs.
Additionally, we offer advanced merchant enrichment using AI to identify merchants from transaction data achieving high accuracy and coverage. Its recurring payment enrichment identifies regular transaction patterns across various payment types. The models also consider amount thresholds when enriching and assigning specific categories.
To further enhance Assess output – we also provide "risk" indicators including:
NDI calculation and thresholds
Income variability & stability
Income shock indicators
Visibility of other/missing accounts
Recent borrowing
High-cost short term lending
Gambling risk measure
Loan repayments exposure
Debt collection warnings
Essential vs non-essential expenditure
Balance over time
Returned direct debits flag
High cash withdrawals
Furthermore, there is the ability to define custom rules to deliver more tailored parameters through the use of Custom Flags/Insights. For each component, clients can set specific parameters such as transaction amounts or relevant categories. These insights can then be run to match customers against the most applicable flags or use cases, enabling more precise segmentation and targeting. They are based on a set of configurable components including:
account balances
income/expense amounts from our granular categories
time periods
and spending with specific merchants
5.7 Technical Evaluation Requirement: API Access for Proof of Concept
You will be required to support a technical Proof of Concept (PoC). To enable this, we request:
Access to a fully functional staging/sandbox environment that mirrors production behaviour as closely as possible.
API documentation and developer support necessary to connect and simulate user journeys for income and expenditure mapping.
Sample/test data for realistic evaluation of API performance, data structures, and security workflows.
Please confirm:
Whether you can provide secure access to a staging or sandbox API environment to support PoC activities.
Any prerequisites (e.g., NDA, access request forms) for provisioning such access.
Expected lead time for provisioning access and support availability during the PoC window.
Any limitations of the staging environment vs production APIs.
1. Whether you can provide secure access to a staging or sandbox API environment to support PoC activities.
Access to the API Sandbox environment is available immediately, allowing Paylink to begin testing and integration without delay. Additionally, access to our Assess web dashboard can be granted for proof-of-concept purposes, enabling the Paylink operational team to conduct manual Open Banking journeys and internal investigations as needed.
To support the PoC, we will provide full API specifications and assign a highly experienced team to ensure the process runs smoothly and exceeds Paylink’s expectations. This setup is designed to deliver a robust and client-focused experience from the outset.
2. Any prerequisites (e.g., NDA, access request forms) for provisioning such access.
As Paylink is TransUnion’s existing partner and we already have agreement in place today, there are no prerequisites required for sign-up of the existing Sandbox
3. Expected lead time for provisioning access and support availability during the PoC window.
Access to the Sandbox APIs is available instantly, allowing Paylink to begin integration and testing without delay. Throughout the UAT process, TransUnion will provide full support to ensure a smooth experience. Full production access will be granted upon completion of contracting, enabling Paylink to deliver enhanced functionality to its clients with confidence.
The sandbox API environment mirrors its production environment, and updates are made in tandem, the only difference is the providers that you can connect to via Open Banking, i.e. on the sandbox environment, you can only connect to the sandbox environment of the different providers and hence interact with dummy data.
Please note some rate limits do apply within the sandbox.
