Tunic Pay Intelligence Interchange Ontology

This document provides guidance for banks participating in Tunic Pay’s Intelligence Interchange. The network facilitates the exchange of data between participants in order to reduce APP Fraud and mitigate undue customer friction originating from false positives.

This guide outlines what network participants can expect to share and receive (the “ontology”). It provides an overview of the security and privacy models used to ensure that data is only readable by the intended party, do not unnecessarily identify any individual, and that commercially sensitive information is not unnecessarily revealed. It also covers the architecture and the protocol itself at high level (more detailed documentation is available separately).

This guide’s intended audience is risk and data science teams. The focus here is on the content of data sharing (i.e. what fields are shared), not the modality (how data is shared). Detailed engineering considerations are addressed in separate documentation.

Note

This document is UK-centric, although we are (gradually) expanding to non-UK usecases (please reach out for localization).

Ontology

This section discusses the fields which can be shared with and received from other Intelligence Interchange participants (the ”ontology”). Tunic Pay maintains the ontology, providing ongoing review, updates, and standardisation.

Fields in the ontology are divided into “modules”, which are logical groupings of fields. These modules are conceptually related fields, but do not require absolute participation; Intelligence Interchange network participants can share subsets of these fields on a give-to-get paradigm. We model three modules:

1. Enhanced Fraud Data “EFD”: this mirrors the work carried out by Pay.UK to build a skeleton “messaging standard.” The explicit aim of EFD was to build something that would “work in a similar manner to Confirmation of Payee…to enable enriched data fields to be shared between PSPs.” The last work undertaken here was completed in March 2023, and the result is a set of fields which privacy and fraud teams across the industry approved. (Note: an update to the EFD standard is expected in late July 2024, and will be reflected in these docs).
2. Augmented Field Exchange “AFX”: This is Tunic Pay’s augmentation of the last published standard referenced above. Our view is that, while EFD is an industry-wide recognition that APP fraud is solved with data-sharing, the existing standard is insufficient. AFX builds on EFD to layer Tunic Pay’s expertise on additional fields that should be shared for each side to assess transactional risk. (Tunic Pay also recognises that this module may evolve, and encourage the feedback of network participants for additions). Some of these fields contain PII and should be subject to privacy review as well as additional architectural choices.
3. Transaction Monitoring Insights “TMI”: this class of data comprises the subset of each side’s transaction monitoring output that will be shared. This module acknowledges that existing TM assessments are (a) one-sided assessments (trivially, each side only currently knows data about their side of the transaction), yet (b) very helpful to know by the other side. Unlike EFD and AFX, which can be generalised to a standard list of fields, Transaction Monitoring outputs across the industry are heterogeneous, with banks using different TM systems and modelling risk in different ways. This data is largely not PII, and not subject to privacy reviews.

Additionally, Tunic Pay has developed a “Quick Start” (QS) Module which represents the minimum data contribution required to participate in the Intelligence Interchange. This is our recommended starting-point for any analytical exercise.

Ontology modules do not require absolute participation. Instead, the Intelligence Interchange operates on a give-to-get paradigm based on the following principles: (1) Minimum data contribution — as laid out in the Quick Start Module, (2) Symmetrical outcomes — higher contributions will result in higher outcomes, albeit the data is always deidentified to protect privacy, (3) Reciprocity — the collective intelligence of the network is leveraged to identify emerging fraud patterns.

1. Enhanced Fraud Data (EFD)

The latest EFD implementation guide (v0.1) outlines approximately 30 fields, laid out as describing one of either:

• the “Party” (the owner of the payer account)
• the “Account” (attributes and datapoints about the payer account)
• the “Payment” (attributes and datapoints about the payee account)

While there’s broad industry-wide agreement that the fields laid out in Pay.UK’s EFD documentation form the backbone of data-sharing, those documents contain some imprecisions and inaccuracies. Tunic Pay has revised that guide, and this module forms the base on which to build the more advanced modules to follow. Field labels have been changed to make them more readable & intuitive for data scientists & fraud officers (e.g. “payer” and “payee” in place of “debtor” and “creditor”, as the former align better with “confirmation of payee”.)

View fields

Field	Provided by	Modules	Description	Data Type	EFD 0.1 Field
Payer Name	Payer PSP	EFD 0.1 (modified by Tunic Pay)Quickstart	Name by which a party is known that owes an amount of money to the  payee and which is usually used to identify that party.	Max140Text	DebtorName
Payer Account IBAN	Payer PSP	EFD 0.1Quickstart	Identifier used internationally by financial institutions to uniquely identify the account of a customer. Further specifications of the format and content of the IBAN can be found in the standard ISO 13616 Banking and related financial services - International Bank Account Number (IBAN) version 1997-10-01, or later revisions.	IBAN2007Identifier	DebtorIBAN
Payer Account Opening Date	Payer PSP	EFD 0.1Quickstart	Date on which the account and related basic services are effectively operational for the payer account owner.	ISO8601Date	DebtorAccountOpeningDate
Payer Sector Codes	Payer PSP	EFD 0.1	UK SIC code(s). Note that EFD 0.1 permits only a single code, whereas Tunic Pay’s implementation permits up to four SIC codes to be supplied.	[ Max6Text, Max6Text, Max6Text, Max6Text ]	DebtorAccountSectorCode
Payer Account Balance	Payer PSP	EFD 0.1	The current available balance in the payer’s account, including any overdraft facility.	[ CcyISO4217Identifier, Decimal518 ]	DebtorAccountAmountBalance
Payer Date of Incorporation	Payer PSP	EFD 0.1Quickstart	The business incorporation or start date, if the payer is a business.	ISO8601Date	DebtorAccountBusinessStartDate
Payer Date of Birth	Payer PSP	EFD 0.1Quickstart	The payer’s date of birth, if the payer is a person.	ISO8601Date	DebtorDateOfBirth
Payment Payee Name	Payer PSP	EFD 0.1Quickstart	The name of the payee as supplied by the payer.	Max140Text	CreditorName
Payment Payee Account Identification	Payer PSP	EFD 0.1	Unique and unambiguous identification for the account between the account owner and the account service. If the payee account is based in the UK, this field must contain the Account Number. Otherwise, Payment Payee IBAN must be used. Note that this is information attached to the payment by the payer, not supplied by the Payee PSP.	Max34Text [0-9]*	CreditorAccountIdentification
Payee Account Opening Date	Payee PSP	EFD 0.1Quickstart		ISO8601Date	CreditorAccountOpeningDate
Payee Sector Codes	Payee PSP	EFD 0.1		[ Max6Text, Max6Text, Max6Text, Max6Text ]	CreditorAccountSectorCode
Payee Average Credit Value	Payee PSP	EFD 0.1	Average of the received credit amounts per transaction over 6 months (that is, payments coming in).	[ CcyISO4217Identifier, Decimal518 ]	CreditorAccountAmountAverage
Payment Amount	Payer PSP	EFD 0.1Quickstart	Amount of money moved between the payer and payee agents.	[ CcyISO4217Identifier, Decimal518 ]	InterbankSettlementAmount
Payment Reference	Payer PSP	EFD 0.1 (modified by Tunic Pay)Quickstart	The reference attached to the payment by the payer	Max35Text	N/A (not in EFD v0.1 spec)
Payer Account Identification	Payer PSP	EFD 0.1 (modified by Tunic Pay)	Unique and unambiguous identification for the account between the account owner and the account service. If the account is based in the UK, this field must contain the Account Number. Otherwise, Payer Account IBAN must be used.	Max34Text [0-9]*	DebtorAccountIdentification
Payee Date of Incorporation	Payee PSP	EFD 0.1 (modified by Tunic Pay)Quickstart		ISO8601Date	CreditorAccountBusinessStartDate
Payee Relationship Date	Payee PSP	EFD 0.1 (modified by Tunic Pay)Quickstart	The date on which the payee’s relationship with the FI began. This may be different from the account opening date.	ISO8601Date	CreditorRelationshipDate
Payer BICFI	Payer PSP	EFD 0.1	Code allocated to a financial institution by the ISO 9362 Registration Authority as described in ISO 9362 Banking - Banking telecommunication messages - Business identifier code (BIC).	BICFIDec2014Identifier	DebtorBICFI
Payer Account Turnover	Payer PSP	EFD 0.1 (modified by Tunic Pay)	Monthly average of the received amounts over a year.	[ CcyISO4217Identifier, Decimal518 ]	DebtorAccountTurnover
Payment Purpose Code	Payer PSP	EFD 0.1 (modified by Tunic Pay)	The purpose for the payment, as designated by the ISO 20022 ExternalPurpose1Code code set.	ExternalPurpose1Code	N/A (not in EFD 0.1 spec)
Payee Account Balance	Payee PSP	EFD 0.1 (modified by Tunic Pay)		[ CcyISO4217Identifier, Decimal518 ]	CreditorAccountAmountBalance
Payee Last Credit Date	Payee PSP	EFD 0.1 (modified by Tunic Pay)	The date of the last credit into the payee’s account.	ISO8601Date	CreditorAccountLastCredit
Payment Payee BICFI	Payer PSP	EFD 0.1	Code allocated to a financial institution by the ISO 9362 Registration Authority as described in ISO 9362 Banking - Banking telecommunication messages - Business identifier code (BIC).	BICFIDec2014Identifier	CreditorBICFI
Payee Date of Birth	Payee PSP	EFD 0.1 (modified by Tunic Pay)Quickstart		ISO8601Date	CreditorDateOfBirth
Payee Account Turnover	Payee PSP	EFD 0.1 (modified by Tunic Pay)		[ CcyISO4217Identifier, Decimal518 ]	CreditorAccountTurnover
Payment Payee IBAN	Payer PSP	EFD 0.1	Identifier used internationally by financial institutions to uniquely identify the account of a customer. Further specifications of the format and content of the IBAN can be found in the standard ISO 13616 Banking and related financial services - International Bank Account Number (IBAN) version 1997-10-01, or later revisions.	IBAN2007Identifier	CreditorAccountIBAN

Excluded EFD 0.1 fields

A handful of fields from the EFD v0.1 spec have been excluded from the Intelligence Interchange ontology for now. The reasons for this are outlined below. Tunic Pay will revisit this as future versions of the EFD spec are published in future.

View fields

EFD 0.1 Field	Description	Reason removed
Message IDs	EFD Message IDs	In Tunic Pay’s Data Sharing, these are carried at the envelope level, not as part of the EFD module.
Debtor Agent Member Identification	FI Identifier of the debtor in the clearing system.	Not predictive of fraud (or stable).
Debtor Account Reference	Unique reference given by the Debtor to identify the payment transaction.	Not predictive of fraud.
Creditor Agent Member Identification	FI Identifier of the creditor in the clearing system.	Not predictive of fraud (or stable).
Purpose Code	Underlying reason for the payment transaction, as published in the EFD Solution purpose (reason) code list.	No such code list exists.
Debtor Account Type Code	Specifies the nature, or use of the account type, in a coded form. Using EFD Solution approved code list	No such code list exists. The ExternalDocumentLineType1Code code set in ISO 20022 is used for other purposes.
Debtor Account SubType Code	Specifies the nature, or use of the account subtype, in a coded form. Using EFD Solution approved code list	No such code list exists. The ExternalDocumentLineType1Code code set in ISO 20022 is used for other purposes.
Creditor Account Type Code	Specifies the nature, or use of the account type, in a coded form. Using EFD Solution approved code list	No such code list exists. The ExternalDocumentLineType1Code code set in ISO 20022 is used for other purposes.
Creditor Account SubType Code	Specifies the nature, or use of the account type, in a coded form. Using EFD Solution approved code list	No such code list exists. The ExternalDocumentLineType1Code code set in ISO 20022 is used for other purposes.

2. Augmented Field Exchange (AFX)

Our philosophy on augmenting the fields exchanged in EFD is to include fields that are easily accessible / sendable by each bank in the transaction. The AFX module comprises fields which relate to the accounts, the parties, and the relationships parties and PSPs:

• Party: apart from the basic information included in the EFD v0.1 specification, Tunic Pay has included additional identity fields that are shown to be predictive in one-sided fraud models but to which banks are blind about the other party.
• Account: similarly, we fill in some of the missing gaps from EFD regarding account-level fields such as recent transaction history.
• Relationship: fields describing the relationship between the PSP and their customer are valuable both as predictors of fraud and to reduce false positive detection.

This module is quite extensive. It can be helpful to decompose it further, especially when considering privacy.

1. AFX - Identity & Account includes point-in-time data describing current characteristics of the account and the customer that holds that account. These fields generally include customer PII.
2. AFX - Change Flags includes derivative and aggregate data which describes trends. Such trends often help to predict fraud in a one-sided model (e.g. recent changes to log-in details) and are also useful to the “other side” of a payment transaction. These fields generally do not contain PII.

The inclusion of PII data in Identity & Account fields permits far more accurate fraud prediction, and necessitates scrutiny from privacy teams. From a compliance perspective:

1. It represents processing under legitimate interest (fraud prevention) and is essential for fulfilling contractual obligations with the payer (payment execution, protection of vulnerable customers / consumer’s financial interests).
2. No automated decision-making is undertaken: in case of potential fraud, the payment is routed to review and manual step-ups.
3. There is no special category data included.

Tunic Pay implements extensive and robust security and privacy protections throughout the Data Sharing architecture and protocol including the option for PII fields to remain locally stored and inaccessible by Tunic Pay under the Enhanced Provider Control.

AFX - Identity & Account

AFX - Identity & Account primarily comprises fields that network participants have available in their databases in approximately the same format. As a result, very little incremental treatment is necessary to standardise these fields. Moreover, these fields constitute PII and will be subject to internal alignment and DPIA review.

View fields

Field	Provided by	Modules	Description	Data Type
Payee Name	Payee PSP	AFX - I&A	Name by which a party is known that owes an amount of money to the  payee and which is usually used to identify that party.	Max140Text
Payee Account Type Code	Payee PSP	AFX - I&A		TnpyAccountType1Code
Payee Last Credit Amount	Payee PSP	AFX - I&A	The amount and currency of the last credit to the payee’s account. This is the same credit as identified by the Payee Last Credit Date field in the EFD module.	[ CcyISO4217Identifier, Decimal518 ]
Payee Account Transaction Monitoring investigation rate	Payee PSP	AFX - I&A	An array of rates of investigations for inbound payments. This is the simple ratio of (payments that triggered investigation / total payments). The elements of the array are the rate over the past 1d, 14d, 30d.	[Decimal518, Decimal518, Decimal518]
Payer Account number of blocks	Payer PSP	AFX - I&A	An array of the number of times the payer account has been blocked. The array contains the number of blocks applied over the past 1d, 14d, 30d.	[nonNegativeInteger, nonNegativeInteger, nonNegativeInteger]
Payee Account number of blocks	Payee PSP	AFX - I&A	An array of the number of times the payee account has been blocked. The array contains the number of blocks applied over the past 1d, 14d, 30d.	[nonNegativeInteger, nonNegativeInteger, nonNegativeInteger]
Payer Account number of investigations	Payer PSP	AFX - I&A	An array of the number of times payments outbound from the payer account have been investigated. The array contains the number of investigations conducted over the past 1d, 14d, 30d.	[nonNegativeInteger, nonNegativeInteger, nonNegativeInteger]
Payee Account number of investigations	Payee PSP	AFX - I&A	An array of the number of times payments inbound to the payee account have been investigated. The array contains the number of investigations conducted over the past 1d, 14d, 30d.	[nonNegativeInteger, nonNegativeInteger, nonNegativeInteger]
Payer Account number of times victim	Payer PSP	AFX - I&A	An array of the number of times the payer has been a victim of APP Fraud. The array contains the number of times in the past 30d, 180d, 360d.	[nonNegativeInteger, nonNegativeInteger, nonNegativeInteger]
Payer Relationship Date	Payer PSP	AFX - I&AQuickstart		ISO8601Date
Payer Geographic Subdivision	Payer PSP	AFX - I&A	The geographic subdivision in which the payer is resident or legally incorporated. This should be the alphanumeric identifier for the smallest known geographic subdivision according to ISO-3166-2 Codes for the representation of names of countries and their subdivisions – Part 2: Country subdivision code.	ISO3166_2_1Identifier [A-Z]{2}\-[A-Z]{1,3}
Payee Geographic Subdivision	Payee PSP	AFX - I&A		ISO3166_2_1Identifier [A-Z]{2}\-[A-Z]{1,3}
Payee Average Account Balances	Payee PSP	AFX - I&A	The average balance on the payee account over the past 1d, 7d, 14d, 30d, 90d, 180d, 365d	[Decimal518, Decimal518, Decimal518, Decimal518, Decimal518, Decimal518, Decimal518]
Payee Average Credit Amounts	Payee PSP	AFX - I&A	The average value of credits to the payee account over the past 1d, 7d 14d, 30d, 90d, 180d, 365d	[Decimal518, Decimal518, Decimal518, Decimal518, Decimal518, Decimal518, Decimal518]
Payee Business Address	Payee PSP	AFX - I&A	The address registered with the bank for the business (if the payee is a business)	PostalAddress24
Last Payer Payee Payment Date	Payer PSP	AFX - I&A	The last date on which a payment was made to this payee, if any has been made in the past.	ISO8601Date
Payee Last Creditor Account Identification	Payee PSP	AFX - I&A		Max34Text [0-9]*
Payee Last Creditor Account BICFI	Payee PSP	AFX - I&A		BICFIDec2014Identifier
Payer Account Type Code	Payer PSP	AFX - I&A	The Account Type Code of the payer account, according to the Tunic Pay account type taxonomy.	TnpyAccountType1Code
Payee Last Creditor IBAN	Payee PSP	AFX - I&A		IBAN2007Identifier
Payee recent IP addresses	Payee PSP	AFX - I&AQuickstart	The distinct IP addresses recorded accessing the payee account over the past 7 days	[IpAddress...]
Payee last IP address	Payee PSP	AFX - I&AQuickstart	The last IP address recorded accessing the payee account	[IpAddress, ISO8601LocalDateTime]
Payee registration IP address	Payee PSP	AFX - I&AQuickstart	The IP address recorded at account opening, if any	IpAddress
Confirmation of Payee result	Payer PSP	AFX - I&A	The result of the Confirmation of Payee check carried out at payment initiation, drawn from the standardized taxonomy of results (COP_RESULT_MATCH, COP_RESULT_CLOSE_MATCH, COP_RESULT_NO_MATCH)	TnpyCopResult1Identifier

AFX - Change Flags

As regards Change Flags, the table below is more idiosyncratic by bank and requires some structuring by participants (although many change flags are dates or numerical aggregates, there is varied ease of collection). If there are any questions about the fields below, Tunic Pay can help advise on best practice, including data mapping for gaps.

View fields

Field	Provided by	Modules	Description	Data Type
Payer Account Transaction Monitoring investigation rate	Payer PSP	AFX - Change	An array of rates of investigations for outbound payments. This is the simple ratio of (payments that triggered investigation / total payments). The elements of the array are the rate over the past 1d, 14d, 30d.	[Decimal518, Decimal518, Decimal518]
Payer Account Oldest Credit Date	Payer PSP	AFX - Change	The date of the oldest credit to the payer account	ISO8601Date
Payer Account Oldest Debit Date	Payer PSP	AFX - Change	The date of the oldest debit from the payer account	ISO8601Date
Payee Account Oldest Credit Date	Payee PSP	AFX - Change	The date of the oldest credit to the payee account	ISO8601Date
Payee Account Oldest Debit Date	Payee PSP	AFX - Change	The date of the oldest debit from the payee account	ISO8601Date
Payee Last Phone Number Change Date	Payee PSP	AFX - Change	The date on which the payee last changed the email address registered with the receiving PSP	ISO8601Date
Payee Last Email Address Change Date	Payee PSP	AFX - Change	The date on which the payee last changed the phone number registered with the receiving PSP	ISO8601Date
Payee Last Password Change Date	Payee PSP	AFX - Change	The date on which the payee last changed their password at the receiving PSP	ISO8601Date
Payee Distinct Payers	Payee PSP	AFX - Change	No. of distinct accounts that transferred money to this account in the past 1d, 14d, 30d, 90d	[nonNegativeInteger, nonNegativeInteger, nonNegativeInteger, nonNegativeInteger]
Payer Distinct Payees	Payer PSP	AFX - Change	No. of distinct accounts that were paid by this payer in the past 1d, 14d, 30d, 90d	[nonNegativeInteger, nonNegativeInteger, nonNegativeInteger, nonNegativeInteger]
Payee Unique Device Fingerprints	Payee PSP	AFX - Change	The number of unique device fingerprints that have acted on the payee account in the past 1d, 7d, 14d, 30d	[nonNegativeInteger, nonNegativeInteger, nonNegativeInteger, nonNegativeInteger]
Payee Account Velocity	Payee PSP	AFX - Change	Ratio of total inbound to total outbound payment value. An array of values calculated over the past 1d, 7d, 14d, 30d, 90d	[Decimal518, Decimal518, Decimal518, Decimal518, Decimal518]
Payee Account Inbound Payments	Payee PSP	AFX - ChangeQuickstart	Number of payments received by (inbound to) the payee account over the past 1d, 7d, 14d, 30d, 90d	[nonNegativeInteger, nonNegativeInteger, nonNegativeInteger, nonNegativeInteger, nonNegativeInteger]
Payer Account Outbound Payments	Payer PSP	AFX - ChangeQuickstart	Number of payments sent by (outbound from) the payer account over the past 1d, 7d, 14d, 30d, 90d	[nonNegativeInteger, nonNegativeInteger, nonNegativeInteger, nonNegativeInteger, nonNegativeInteger]
Payee last name change	Payee PSP	AFX - Change	Date of the last name change on the payee account, if any	ISO8601Date
Payee last wallet port date	Payee PSP	AFX - Change	The date on which a digital wallet payment option for the payee account was last ported between devices	ISO8601Date
Payer last wallet port date	Payer PSP	AFX - Change	The date on which a digital wallet payment option for the payer account was last ported between devices	ISO8601Date

3. Transaction Monitoring Insights (TMI)

Our data fields for this module are a general starting point for the Tunic Pay harmonisation across multiple (including in-house) Transaction Monitoring software solutions.

It is worth noting that outputs from TM systems are disparate in structure, form, and, crucially, semantics: given they provide contextual and fickle “opinions” derived from facts. Nonetheless, their outputs are of potential value to a PSP “on the other side”. The Intelligence Interchange is agnostic to output format as long as it is broadly characteristic of any enterprise-grade TM (e.g. anomalous payment flag, scoring or binary alerts for particular fraud typologies, etc.). As such, the table below is indicative of the data supported by Tunic Pay infrastructure, and mapping into this form is part of the process of a Tunic Pay integration.

View fields

Field	Provided by	Modules	Description	Data Type
Payer PSP Transaction Monitoring scores	Payer PSP	QuickstartTMI	An optional array of fraud scores from either the inbound or outbound TM system. Each score in the array is a tuple of: - a value in the range [0, 1] representing the suspicion of a fraud - a model type code describing what the model is designed to detect (e.g. FRAUD_SCORE_TYPE_AGGREGATE, FRAUD_SCORE_TYPE_PURCHASE, …)	[[Decimal51, TnpyScamTypology1Identifier]...]
Payer PSP Transaction Monitoring flags	Payer PSP	QuickstartTMI	An array of semantic TM flags. Examples below but requiring specific mapping per network participant. TM_FLAG_ANOMALOUS_PAYMENT_AMOUNT, TM_FLAG_HIGH_RISK_JURISDICTION , TM_FLAG_USER_GEOLOCATION , …	[TnpyTmFlag1Identifier...]
Payee PSP Transaction Monitoring scores	Payee PSP	QuickstartTMI	An optional array of fraud scores from either the inbound or outbound TM system. Each score in the array is a tuple of: - a value in the range [0, 1] representing the suspicion of a fraud - a model type code describing what the model is designed to detect (e.g. FRAUD_SCORE_TYPE_AGGREGATE, FRAUD_SCORE_TYPE_PURCHASE, …)	[[Decimal51, TnpyScamTypology1Identifier]...]
Payee PSP Transaction Monitoring flags	Payee PSP	QuickstartTMI	An array of semantic TM flags. Examples below but requiring specific mapping per network participant. TM_FLAG_ANOMALOUS_PAYMENT_AMOUNT, TM_FLAG_HIGH_RISK_JURISDICTION , TM_FLAG_USER_GEOLOCATION , …	[TnpyTmFlag1Identifier...]
Payment Reason Code	Payer PSP	TMI	An identifier describing the stated reason the payer is making the payment. Examples below but requiring specific mapping per network participant. RSN_RIENDS_AND_FAMILY / RSN_SELF / RSN_INVOICE / RSN_INSTRUCTED / …	TnpyPaymentReason1Identifier
Payer vulnerability flags	Payer PSP	TMI	An array of semantic flags describing known indicators of vulnerability for the payer. Examples below but requiring specific mapping per institution. VULN_FLAG_PREVIOUS_VICTIM / VULN_FLAG_SELF_DISCLOSURE / VULN_FLAG_AGE / VULN_FLAG_FINANCIAL_SITUATION / VULN_FLAG_OTHER / …	[TnpyVulnFlag1Identifier...]
Payee vulnerability flags	Payer PSP	TMI	An array of semantic flags describing known indicators of vulnerability for the payee. Examples below but requiring specific mapping per institution. VULN_FLAG_PREVIOUS_VICTIM / VULN_FLAG_SELF_DISCLOSURE / VULN_FLAG_AGE / VULN_FLAG_FINANCIAL_SITUATION / VULN_FLAG_OTHER / …	[TnpyVulnFlag1Identifier...]
Payee number of step-ups	Payee PSP	TMI	The number of frictionful engagements the payee underwent in relation to this payment.	nonNegativeInteger
Payer number of step-ups	Payer PSP	TMI	The number of frictionful engagements the payer underwent in relation to this payment.	nonNegativeInteger

4. Quick Start (QS)

Tunic Pay has developed a Quick Start module comprised of fields from across the rich module specification for Intelligence Interchange. These QS fields provide a baseline for proof of concept assessment and a means to analyse predictiveness. These fields represent:

• FPS payment instructions
• Length of relationship of the payer and payee with their individual banks
• Activity of each account
• Transaction monitoring scores & flags

Note

💡 Keep in mind that several of the QS fields (e.g. Payer Name, Payee Name, Payment Reference, Payment Amount, etc. are additionally exchanged in FPS messaging)

Such a study should focus on domestic payments between two participating PSPs executed over FPS rails. Sample data should be at least 3 months old (ideally 6+ months) to balance recency and the need for any fraud to have been reported; this parameter can be tuned based on historical measurements of reporting delays. Studies look different for every institution; please contact us for help designing a study which is appropriate to your needs.

View fields

Field	Provided by	Modules	Description	Data Type
Payer Name	Payer PSP	EFD 0.1 (modified by Tunic Pay)Quickstart	Name by which a party is known that owes an amount of money to the  payee and which is usually used to identify that party.	Max140Text
Payer Account IBAN	Payer PSP	EFD 0.1Quickstart	Identifier used internationally by financial institutions to uniquely identify the account of a customer. Further specifications of the format and content of the IBAN can be found in the standard ISO 13616 Banking and related financial services - International Bank Account Number (IBAN) version 1997-10-01, or later revisions.	IBAN2007Identifier
Payer Account Opening Date	Payer PSP	EFD 0.1Quickstart	Date on which the account and related basic services are effectively operational for the payer account owner.	ISO8601Date
Payer Date of Incorporation	Payer PSP	EFD 0.1Quickstart	The business incorporation or start date, if the payer is a business.	ISO8601Date
Payer Date of Birth	Payer PSP	EFD 0.1Quickstart	The payer’s date of birth, if the payer is a person.	ISO8601Date
Payment Payee Name	Payer PSP	EFD 0.1Quickstart	The name of the payee as supplied by the payer.	Max140Text
Payee Account Opening Date	Payee PSP	EFD 0.1Quickstart		ISO8601Date
Payment Amount	Payer PSP	EFD 0.1Quickstart	Amount of money moved between the payer and payee agents.	[ CcyISO4217Identifier, Decimal518 ]
Payment Reference	Payer PSP	EFD 0.1 (modified by Tunic Pay)Quickstart	The reference attached to the payment by the payer	Max35Text
Payer PSP Transaction Monitoring scores	Payer PSP	QuickstartTMI	An optional array of fraud scores from either the inbound or outbound TM system. Each score in the array is a tuple of: - a value in the range [0, 1] representing the suspicion of a fraud - a model type code describing what the model is designed to detect (e.g. FRAUD_SCORE_TYPE_AGGREGATE, FRAUD_SCORE_TYPE_PURCHASE, …)	[[Decimal51, TnpyScamTypology1Identifier]...]
Payer PSP Transaction Monitoring flags	Payer PSP	QuickstartTMI	An array of semantic TM flags. Examples below but requiring specific mapping per network participant. TM_FLAG_ANOMALOUS_PAYMENT_AMOUNT, TM_FLAG_HIGH_RISK_JURISDICTION , TM_FLAG_USER_GEOLOCATION , …	[TnpyTmFlag1Identifier...]
Payee PSP Transaction Monitoring scores	Payee PSP	QuickstartTMI	An optional array of fraud scores from either the inbound or outbound TM system. Each score in the array is a tuple of: - a value in the range [0, 1] representing the suspicion of a fraud - a model type code describing what the model is designed to detect (e.g. FRAUD_SCORE_TYPE_AGGREGATE, FRAUD_SCORE_TYPE_PURCHASE, …)	[[Decimal51, TnpyScamTypology1Identifier]...]
Payee PSP Transaction Monitoring flags	Payee PSP	QuickstartTMI	An array of semantic TM flags. Examples below but requiring specific mapping per network participant. TM_FLAG_ANOMALOUS_PAYMENT_AMOUNT, TM_FLAG_HIGH_RISK_JURISDICTION , TM_FLAG_USER_GEOLOCATION , …	[TnpyTmFlag1Identifier...]
Payer Relationship Date	Payer PSP	AFX - I&AQuickstart		ISO8601Date
Payee Date of Incorporation	Payee PSP	EFD 0.1 (modified by Tunic Pay)Quickstart		ISO8601Date
Payee Relationship Date	Payee PSP	EFD 0.1 (modified by Tunic Pay)Quickstart	The date on which the payee’s relationship with the FI began. This may be different from the account opening date.	ISO8601Date
Payee Date of Birth	Payee PSP	EFD 0.1 (modified by Tunic Pay)Quickstart		ISO8601Date
Payee Account Inbound Payments	Payee PSP	AFX - ChangeQuickstart	Number of payments received by (inbound to) the payee account over the past 1d, 7d, 14d, 30d, 90d	[nonNegativeInteger, nonNegativeInteger, nonNegativeInteger, nonNegativeInteger, nonNegativeInteger]
Payer Account Outbound Payments	Payer PSP	AFX - ChangeQuickstart	Number of payments sent by (outbound from) the payer account over the past 1d, 7d, 14d, 30d, 90d	[nonNegativeInteger, nonNegativeInteger, nonNegativeInteger, nonNegativeInteger, nonNegativeInteger]
Payee recent IP addresses	Payee PSP	AFX - I&AQuickstart	The distinct IP addresses recorded accessing the payee account over the past 7 days	[IpAddress...]
Payee last IP address	Payee PSP	AFX - I&AQuickstart	The last IP address recorded accessing the payee account	[IpAddress, ISO8601LocalDateTime]
Payee registration IP address	Payee PSP	AFX - I&AQuickstart	The IP address recorded at account opening, if any	IpAddress

---

Architecture and Protocol

The typical flow for two PSPs to exchange data about their customers is as follows:

1. The first PSP — typically the payer’s — communicates with Tunic Pay. It provides data about its customer in fields drawn from the ontology modules.
2. Tunic Pay creates a request to the second PSP (typically the payee’s), and this is answered with corresponding information about that PSP’s customer. At this stage, Tunic Pay infrastructure holds data from both PSPs, but no exchange has taken place yet.
3. The Share is completed by forwarding the consumer data to the PSPs on the “other side” of the payment simultaneously.

The Intelligence Interchange is architected around a three-party model, with different roles and responsibilities for each party — namely:

• The Share Initiator (SI) is the entity which triggers Interchange (the first PSP above), initiating a Share;
• Tunic Pay in its role as mediator of the Share provides escrow, and crucially security and privacy enhancement over the data;
• The Share Responder (SR) is the entity which completes a Share by returning its own data (the second PSP above).

Privacy and security of data are central to this protocol and to the architecture which supports it. The architectural and technical measures taken to support these concerns are documented in detail below.

Throughout this guide, in the context of fields exchanged in a Share, we also refer to:

• Data Provider (DP): the party which is sharing data using Intelligence Interchange
• Data Requester (DR): the party which requested data using Intelligence Interchange

Both the SI and SR will act as Data Providers during the course of a Share.

Security

Tunic Pay’s Intelligence Interchange has been designed from the ground up to provide best-in-class security. This provides participants with strong guarantees that shared data is only readable by the intended party. As well as being secure by design, the Intelligence Interchange provides strong privacy protections which are covered elsewhere in this guide.

Security features are built in at both the architectural and protocol levels. Nonetheless, we believe it should be easy to do the right thing, so for integration purposes security concerns are largely abstracted behind domain-oriented APIs which are recommended for most participants. Tunic Pay is also developing lower-level APIs which provide the same security guarantees and may provide greater control at the cost of higher integration; we can help advise on these.

Data sent through Intelligence Interchange is never stored or transmitted in plaintext. Envelope encryption is used, separating data encryption from key encryption and allowing us both enforce significant controls on data access. A federated key management approach means that data providers can unilaterally and non-destructively revoke access to their data. These concepts are covered in more detail below.

Security models

We offer a two-tier model for sharing data through Intelligence Interchange:

• Baseline — recommended for the majority of the Intelligence Interchange
• Enhanced Provider Control

Both operate on the same security architecture, offer the same guarantees, and use the same robust encryption.

Under our federated key management architecture, root keys are managed differently: Baseline root keys are managed by Tunic Pay, while in Enhanced Provider Control root key management is handled by the Data Provider, which affords granular control over encryption at a per-field level. This means access to data sent using Enhanced Provider Control can be revoked at any time by the DP, or even partially revoked such that only certain fields remain externally available.

At this time, Enhanced Privacy Control is available for AFX Identity & Account fields and by prior arrangement with Tunic Pay.

Data Security

At a high level, the Intelligence Interchange uses symmetric encryption with key rotation on each access by the data requester to ensure that no plaintext is ever transmitted or stored outside your environment. Tunic Pay uses a unique, derived key for each Share (or field with Enhanced Provider Control) and decouples data encryption from IAM/permissions. This allows us to rotate keys regularly without updating all encrypted data. We can, therefore, offer a federated model whereby any party providing data over Intelligence Interchange can choose and manage the root key at a field/Share level.

Envelope Encryption

The Intelligence Interchange protects data with Envelope Encryption. Data is encrypted with a Data Encryption Key (DEK) which is then itself encrypted with a Key Encryption Key (KEK). This allows Data Encryption Keys to reside alongside encrypted data without compromise and ensures that only the encrypted DEK need be updated when rotating the KEK.

All KEKs are derived from a root key and a secret. The root key resides at (and never leaves) the Key Management System, and the secret resides at (and never leaves) Tunic Pay. We derive a fresh KEK on every access to customer data.

On receipt, a Share can safely be stored as the data contained (an encrypted payload and an encrypted DEK) are unreadable without the correct KEK. A request to Tunic Pay servers is needed to retrieve the KEK; this triggers KEK rotation and re-encryption of the DEK such that subsequent access to the data requires further requests to Tunic Pay.

Ciphers

Separating how we encrypt data (the DEK) from how we encrypt secrets needed to read them (KEK) gives us flexibility to select the most appropriate cipher (with respect to both vulnerability and computational burden on the customer). This separation also allows us to change the cryptographic parameters (cipher / key length / number of rounds) without re-encrypting underlying data.

We build on industry best practises such as those used by AWS, GCP and Azure to operate highly sensitive applications across healthcare, finance and critical government infrastructure including defence. As such, we use:

• AES GCM for symmetric encryption of data and keys
• Elliptic Curve Cryptography (Curve25519) for asymmetric encryption to authenticate data

These methods are well supported in modern software and hardware, and are non-proprietary (i.e. fully open-source software such as openssl can be used both to sign and to validate messages using ECDSA with the 25519 curve).

Zero Trust guarantees

We implement zero trust in our architecture by making the following guarantees:

• Customer data is never stored in plaintext
• Encrypted customer data is never transmitted or stored alongside its KEK
• Customer data is never transmitted more than once encrypted with the same DEK
• mTLS is used at every integration point to verify requests and encrypt traffic
• Our protocol carries the MAC for each field to demonstrate integrity and provenance

Key Management

Key management for Baseline shares is handled by Tunic Pay. When using Enhanced Provider Control, a data provider can choose the root key used at every stage.

We integrate with a number of key management products including popular cloud and self-hosted solutions such as GCP/AWS/Azure KMS or Hashicorp’s Vault. You can either grant Tunic Pay permission to the key(s) you wish to use or let us handle key management for you.

DEKs are always stored and transmitted encrypted, and a new unique KEK is generated every time there’s a request to read customer data. This KEK is based on a root key that never leaves the key management system.

Data Management

There are two points in this journey when the information is available in plaintext:

1. When the Data Provider responds to a request from the Tunic Pay Connector
2. When a Data Requester successfully requests a decrypted data point from the Tunic Pay Connector

The Tunic Pay Connector is run within your own environment, and always uses mTLS to encrypt traffic and verify requests. Where possible, communication with Tunic Pay’s servers can be handled without travelling over the public Internet by connecting through GCP Private Connect Service or Azure/AWS PrivateLink.

We believe it should be Easy to Do The Right Thing so data requests get a well structured record with the encrypted fields requested, the encrypted DEK, a locator to request the KEK, and a MAC for each field. This record can be safely stored in its entirety, and includes all the information needed both to decrypt it (given the right permissions) and a way to verify it matches what the provider sent. The Tunic Pay Connector provides the integration layer necessary to abstract this complexity from other systems.

What happens in a Share

When a new Share is initiated through Intelligence Interchange, a SI will ask for some fields and Tunic Pay routes that request to the correct SR.

SR generates a key (DEK) and encrypts the information they’re responding with then sends it alongside the encrypted DEK and a locator for the KEK.

We store that encrypted data and DEK, then separately add a locator for the KEK to a ledger.

To respond to the data request, we create a new, unique KEK using a per-request secret which never leaves our system. We then send the encrypted data, encrypted DEK and MAC on to SI.

SI stores this encrypted response and when they want to read any field(s) from it, requests their decryption key from the Tunic Pay Connector. This requests the appropriate KEK from Tunic Pay; we rotate the KEK, then respond with both the previous KEK (needed to read the encrypted DEK the DR holds) and that DEK re-encrypted with the latest KEK.

The Tunic Pay Connector uses the old KEK to decrypt the DEK within your environment, and then uses the DEK to decrypt the requested field(s). It verifies that the MAC both matches the plaintext and is signed by the DP; then returns the plaintext.

Enhanced Provider Control

When sharing fields using Enhanced Provider Control, the overall journey of that data is the same as above with an important exception: the root keys used to generate KEKs are chosen and managed by the DP.

Whenever the DR tries to read any fields with Enhanced Provider Control, both they and Tunic Pay need access to the root key in order to decrypt the DEK successfully. This means the DP can revoke access at any time (making encrypted data unreadable) and monitor usage of that key through their own cloud provider.

Tunic Pay persistence

Tunic Pay stores four pieces of information for every Intelligence Interchange request:

• The encrypted data and encrypted DEK from the DP
• A locator for the DP KEK (i.e. root key id and salt)
• The DEK for the DR
• A locator for generating the next DR KEK (i.e. root key id, salt and number of reads)

Our use of envelope encryption means we can still rotate the KEK that the DR needs to read the original information without direct knowledge of it; we only need to know the DR DEK.

Consequently, the DP can at any time revoke permission to use the root key for their KEK, preventing others from decrypting their data without affecting the experience for the DR.

Network Security

In principle, Intelligence Interchange could operate over an insecure network while still protecting the security of the data transmitted. Nevertheless, we take a number of steps to secure transmission over the Intelligence Interchange and ensure that (a) the identity of all participants is verified on every request, and (b) traffic travels within a customer or Tunic Pay controlled VPC wherever possible.

Zero Trust

The Intelligence Interchange is built around the principle of zero trust and ensures that no plaintext is available to any party able to intercept messages passed through the system without additional authorisation/knowledge (even if they do so from within a trusted network perimeter).

By ensuring that a usable decryption key is never stored or transmitted along with something it decrypts (e.g. data and decrypted DEK, or encrypted DEK and and KEK) and relying on a separate key management service with customer-controlled IAM, we are confident in our guarantees of zero trust. In the event of significant exfiltration of data from your environment (e.g. you are the victim of a catastrophic data breach), no encrypted customer data is readable. Furthermore, ongoing access to data can be revoked en masse, unilaterally by you, by revoking access to the root key(s). This non-destructively removes all value from encrypted data as no-one has enough knowledge to use the DEK; the secret is controlled jointly by Tunic Pay and by you.

Private backhaul

For customers using AWS, GCP or Azure, we can provide an endpoint for Private Link/Private Connect Service meaning communication with Tunic Pay never travels over the public Internet.

mTLS

Every integration point in the Intelligence Interchange enforces mTLS. Clients are always required to sign requests. We will provide simple integrations with multiple cloud providers (starting with AWS and GCP) for our federated IdP to make controlling IAM permissions for root keys as easy as possible.

Privacy

Note

💡 This documentation is focused on UK-jurisdictional privacy considerations (e.g. UK GDPR). Please refer to other guidance or contact Tunic Pay for privacy documentation relating to other jurisdictions or cross-jurisdiction sharing.

The Intelligence Interchange offers best-in-class privacy by design to protect consumer identity while facilitating data sharing.

At an architectural level, numerous features protect identity, such as independent transmission, encryption, and persistence of indentifiable and depersonalized data. These measures are outlined throughout this guide.

At a protocol level, the Intelligence Interchange supports flexible, declarative privacy policies which alter data shared by participants to protect privacy and decrease the possibility of consumers being identified by the data. These transformations are automatically applied by the Interchange to prevent unaltered data from being shared.

In order for it to be easy to do the right thing, privacy concerns are largely abstracted behind the Interchange APIs, similarly to security considerations. A default privacy policy is in place covering all Interchange fields; this can be tailored by participants where necessary. The privacy enhancing layer of the Intelligence Interchange is maintained by Tunic Pay, which supports a growing set of additional transformations beyond those available today.

Privacy enhancing techniques

The following sections outline techniques that can be applied to different fields in an Intelligence Interchange privacy policy, along with examples of where our default policy uses these fields.

Tokenization

The Intelligence Interchange supports automatic tokenization of field values to depersonalize data. Since data is not fully anonymized through tokenization, Tunic Pay has robust security measures in place to prevent de-identification at both the architecture and protocol levels which are documented elsewhere in this guide.

By default, tokens are best-effort one-to-one replacements. As such, tokens can be reverse-engineered provided enough additional identifying information is known. To help mitigate this, the Intelligence Interchange additionally provides probabilistic many-to-one and many-to-many tokenization schemes. Since such techniques can dramatically impact the predictiveness of data, we do not recommend broad application of these; often other PETs are better served instead.

Example of use

The default privacy policy for Intelligence Interchange applies tokenization to the Payee name.

{
  "creditor": {
    "name": "Alex Taylor",
    ...
  }
}

{
  "creditor": {
    "name": "01J1D9S6VF71Y4NN9WSZ21MKFP",
    ...
  }
}

Generalization

By reducing the granularity of data, generalization serves to obfuscate identifiable information. This transformation is lossy, but any decrease in statistical significance can be measured and the granularity of generalization can be tuned in policy.

Example of use

Tunic Pay’s default privacy policy for Intelligence Interchange applies generalization to Dates of Birth and Incorporation, clamping both to month/year.

{
  "debtor": {
    "date_of_birth": "1970-02-21",
    ...
  }
}

{
  "debtor": {
    "date_of_birth": "1970-02",
    ...
  }
}

Aggregation

The Intelligence Interchange can automatically derive aggregates from data as a powerful anonymization technique. Policies can be specified which automatically aggregate raw data e.g. through averages (fixed / sliding / moving), bounds functions, etc.

Example of use

As well as supporting aggregation at the policy level, the Intelligence Interchange bakes aggregation into its ontology in several fields. For example, shifting trends in data are described using moving averages in fields such as Payer Distinct Payees and Payee Account Velocity. The Tunic Pay Connector can automatically apply these techniques when integrated with raw data sources.

Data handling

Data Retention

The Intelligence Interchange operates a nuanced data retention strategy which minimizes identifiable data retained by Tunic Pay while supporting the need to audit the data exchanged up to and beyond the window for APP Fraud claims.

All data shared through the Intelligence Interchange is retained in its original, encrypted form by Tunic Pay for 24 months. After this retention period, the data will be securely deleted and no audit by participants of what has been shared is possible. The 24 month period is chosen to reduce the possibility that participants can no longer audit what was shared within 13 months of the final payment made to a fraudster — though this is still possible in the event that payments span more than an eleven-month duration.

Within the 24 month period, Tunic Pay may use multiple different storage technologies to house this data, including tiered archiving to higher latency storage backends. However, the core guarantees underpinning security and privacy are preserved irrespective of the specific storage technology in use.

In addition to persistence of the original shared data, Tunic Pay may store copies or derivatives of the original data for the development of its own fraud detection and prevention products. Any such copy or derivate subject to additional privacy enhancing techniques including K-Anonymizing duplication, masking and re-tokenization, aggregation, mixing with synthetic data, etc. All such data is re-encrypted by Tunic Pay and thereby disassociated from any prior or existing ID, DEK, or KEK.

The Intelligence Interchange retention policy is aided by automated metadata tagging, and deletion is carried out automatically.

Tunic Pay regularly reviews retention policy and audits compliance.

Purpose Limitation

Data shared through the Intelligence Interchange is used solely for the intended purpose, and the Interchange automatically applies the relevant protections to data to guarantee this.

All data shared is automatically tagged with metadata indicating its purpose, origin, and lineage. Internally, the Interchange tracks the journey of data throughout its lifecycle and applies dynamic access protections derived from these tags, including based on purpose. Regular audits and continuous monitoring ensure compliance with purpose limitations, with detailed logs maintained for all data access and processing activities.

Tunic Pay regularly reviews purpose limitation policy and compliance.

---

Change history

View history

• Initial Release: v0.0.1 (Initial release, includes basic fields for EFD and AFX)
• Patch: v0.0.2 (Clarified fields removed from EFD)
• Minor: v0.1.0 (Split AFX into identity & account data vs. change flags)
• Patch: v0.1.1 (Updated “payee account credit amount” to incorporate more date ranges )
• Patch: v0.1.2 (Removed architecture references)
• Minor: v0.2.0 (Removed lower priority AFX fields)
• Minor: v0.3.0 (Added Transaction Monitoring Insights TMI, no breaking changes)
• Patch: v0.3.1 (Removed EFD equivalence and re-defined terms in absolute)
• Patch: v0.3.2 (Added vulnerability flags to TMI)
• Patch: v0.3.3 (Fixed non-displaying field tables)
• Minor: v0.4.0 (Added Quick Start module, deprecated some old fields, provided Architecture, Security documentation)
• Patch: v0.4.1 (Edited copy for clarity)
• Minor: v0.5.0 (Added first device fields)
• Patch: v0.5.1 (Added Privacy documentation)
• Patch: v0.5.2 (Fixed typos in field descriptions)