Supplemental Data Ingestion for Payment Risk Platform
With Supplemental Data Ingestion you can send supplemental dispute data to Payment Risk Platform (PRP) to be leveraged for developing risk signals, building rules, and models. Data is sent through Secure File Transfer Protocol (SFTP) using the appropriate data schemas based on the use case.
Although PRP detects suspicious authorizations in real time, it may not have full insight into post-authorization data such as dispute details, customer risk data, or any of your internal data. Integrating external data with PRP can provide a more comprehensive understanding of your customers, the merchants they transact with, and their behavior. This expanded visibility enables the detection of more sophisticated risk signals, such as cardholder dispute rates and merchant fraud rates. Supplemental Data Ingestion is especially valuable if you have additional data outside of SoFi Tech Solutions and want to develop advanced risk signals to improve your fraud-detection capabilities.
Key benefits
By pushing more data to SoFi Tech Solutions through Supplemental Data Ingestion, you enable PRP to become a single source of truth for risk management. This allows you to:
- Build rules and generate risk signals — Develop advanced risk signals and build rules to gain deeper insight into account holder behavior, helping you identify risky patterns and anomalies.
- Protect cardholders with custom blacklists — Implement custom merchant blacklists to enhance cardholder protection.
- Improve machine-learning performance — Depending on the use case, your additional data may be used in SoFi Tech Solutions' proprietary machine-learning models, keeping them fresh and accurate to detect suspicious behavior. This also enables the potential to develop your own specific machine-learning models.
- Transaction GScore — If you leverage SoFi Tech Solutions' Transaction GScore, disputes data is a critical component for machine-learning model training and tuning, and providing this data establishes the complete feedback loop necessary for continuous model improvement.
Use cases
Currently, SoFi Tech Solutions specifically supports ingesting disputes data to PRP for clients who do not process disputes through SoFi Tech Solutions but utilize PRP. This provides a crucial feedback loop for authorization into PRP, capturing the complete lifecycle of customer spending. In the future, SoFi Tech Solutions will support other data sets such as customer risk profile, and merchant blacklist/whitelists, which can be utilized to develop features, rules, and models within PRP. If you have additional supplemental data use cases, contact SoFi Tech Solutions to help assess and support your needs on an ad-hoc basis.
Implementation
Contact SoFi Tech Solutions to set up Supplemental Data Ingestion for your program.
Setup for Supplemental Data Ingestion for PRP (Custom page)
This guide describes developer implementation for Supplemental Data Ingestion for Payment Risk Platform (PRP). For general information, see Supplemental Data Ingestion for PRP.
SFTP setup
Setting up the SFTP server and providing the necessary credentials generally takes 2–3 weeks. During this setup phase, SoFi Tech Solutions requires specific information from you for IP whitelisting, SSH keys, and file encryption details. We then provide you with the encryption public key, which you must use to encrypt your files. Once testing is complete, you can begin sending files to the production folder.
You will transfer your files to the /risk-dispute folder on the SFTP server.
Note
SoFi Tech Solutions handles duplicate records by taking the latest records based on the timestamp you provide in the file.
Data requirements
You are responsible for adhering to the necessary schema and generating files correctly. Any issues in the data you provide may impact PRP's performance, and corrections to data may incur fees. To prevent issues, we recommend that you share a sample file with SoFi Tech Solutions for validation before you begin pushing actual data to the SFTP server.
File format
You must adhere to a precise file naming convention: [yourname]-disputes-YYYY-MM-DD-hh-mm-ss.csv. The YYYY-MM-DD-hh-mm-ss portion represents the date and time the file was created. This timestamp helps SoFi Tech Solutions track data and investigate any future errors. All files you transfer must be CSV files with a .gpg security extension.
Warning
Only CSV files are supported for data ingestion.
Data schema
The specific data schema can vary by use case, so ask your SoFi Tech Solutions representative for the exact schema relevant to your implementation. For the dispute data use case, your CSV files will include various fields, each with specific requirements for source, data type, and format. Each field specifies its source (whether you or SoFi Tech Solutions' RDF provides the value), data type, a description of its purpose and content, whether it is required or optional, and example values.
| Field | Source | Required | Data type | Description |
|---|---|---|---|---|
event_type | you | X | VARCHAR(50) | The name of this event. Example: debit_update |
event_ts | you | X | TIMESTAMP_NTZ(3) | Date-time this event was created in Mountain Standard Time. Pass the date and time as a single value, without any associated time zone. Format: YYYY-MM-DD hh:mm:ssExample: 2025-01-31 17:20:33 |
db_id | Account Card RDF | X | NUMBER(10,0) | The database ID provided by SoFi Tech Solutions. Max 10 digits. Example: 999 |
prn | Posted Trans RDF | X | VARCHAR(12) | SoFi Tech Solutions 12-digit PRNfor the account. This field correlates with the PRN field in the Posted Transactions RDF.Example: "999101003022" |
prog_id | Posted Trans RDF | X | NUMBER(18,0) | The identifier that SoFi Tech Solutions has assigned to your Program. This field correlates with the UNIQUE PROGRAM ID field in the Posted Transactions RDF.Example: 305 |
auth_id | Auth Trans / Posted Trans RDFs | X | NUMBER(18,0) | System-generated ID for the authorization request. This ID is unique per subnetwork. This field correlates with the AUTHORIZATION CODE field in the Posted Transactions RDF. Example: 12303090 |
association | Posted Trans RDF | VARCHAR(32) | Three-letter abbreviation for the card network:DEB (Maestro)MAS (Mastercard credit)STA (STAR)VIS (Visa)DIS (Discover)ALL (Allpoint)PLS (Pulse) This field correlates with the ASSOCIATION field in the Posted Transactions RDF. | |
source | Auth Trans / Posted Trans RDFs | NUMBER(1,0) | Number assigned to a network: - 1 Maestro - 2 Mastercard credit - 3 STAR - 4 Visa - 5 Discover - 6 Allpoint - 7 Pulse This field correlates with the SOURCE field in the Posted Transactions RDF. | |
settle_ts | Posted Trans RDF | X | TIMESTAMP_NTZ(3) | Date-time the disputed transaction was settled in Mountain Standard Time. Pass the date and time as a single value, without any associated time zone. This field correlates with the SETTLE DATE field in the Posted Transactions RDFFormat: YYYY-MM-DD hh:mm:ssExample: 2025-01-31 17:20:33 |
dispute_id | you | X | NUMBER(18,0) | Unique identifier for the dispute. Example: 12432 |
dispute_ts | you | X | TIMESTAMP_NTZ(3) | Date-time when the dispute was created in Mountain Standard Time. Pass the date and time as a single value, without any associated time zone. Format: YYYY-MM-DD hh:mm:ssExample: 2025-01-31 17:20:33 |
dispute_reason | you | X | VARCHAR(50) | The reason for the dispute. See Standard dispute reasons for valid values. Example: "DUPLICATE" |
dispute_amt | you | X | NUMBER(14,2) | The amount of the dispute, with two decimal places. Example: 3245.22 |
is_disputed | you | X | NUMBER(1,0) | Dispute flag. 1 — Yes Format: 1 or 0. |
is_fraud | you | X | NUMBER(1,0) | Fraud credit flag. 1 — Yes 0 — No Format: 1 or 0. If no data exists, leave null. |
resolution | you | X | VARCHAR(50) | Possible resolution values:CHARGEBACKWRITE_OFFCUSTOMER_LOSSMERCHANT_CREDITSee Standard resolution status mapping to map the values passed to SoFi Tech Solutions to the relevant status from the dispute processor. If no data exists, leave null. |
resolution_ts | you | X | TIMESTAMP_NTZ(3) | Date-time the claim investigation was finalized in Mountain Standard Time. Pass the date and time as a single value, without any associated time zone. Format: YYYY-MM-DD hh:mm:ddExample: 2024-10-11 16:04:23If no data exists, leave null. |
dispute_lag | you | NUMBER(9,0) | The number of days elapsed between settle_ts and dispute_ts. | |
pc_credit_flag | you | X | NUMBER(1,0) | Whether provisional credit was awarded: 1 — Yes 0 — No Format: 1 or 0If no data exists, leave null. |
pc_amt | you | FLOAT | The amount of provisional credit awarded with two decimal places. Example: 34.65 If no data exists, leave null. | |
pc_ts | you | TIMESTAMP_NTZ(3) | The date the provisional credit was awarded. Format: YYYY-MM-DD hh:mm:dd Example: 2025-04-03 17:43:23 If no data exists, leave null. | |
pc_reversal_amt | you | NUMBER(14,2) | The amount of provisional credit reversed, with two decimal places. Example: 41.05 If no data exists, leave null. | |
pc_reversal_ts | you | TIMESTAMP_NTZ(3) | The date-time the provisional credit was reversed in Mountain Standard Time. Pass the date and time as a single value, without any associated time zone. Format: YYYY-MM-DD hh:mm:dd Example: 2024-12-11 17:43:23 | |
xid | Posted Trans RDF | NUMBER(18,0) | Internal system-generated ID for an account. This field correlates with the XID field in the Posted Transactions RDF.Example: 13162 | |
cad | Posted Trans RDF | NUMBER(18,0) | System-generated card ID. This field correlates with the CARD IDENTIFIER field in the Posted Transactions RDF. Example: 13162 |
Standard dispute reasons
These are the valid values for the dispute_reason field. String length is up to 50 characters
| Value passed to SoFi Tech Solutions |
|---|
MERCHANDISE SERVICES NOT RECEIVED |
MERCHANDISE SERVICES NOT AS DESCRIBED |
INCORRECT CHARGE |
FUNDS NOT DISPENSED |
UNAUTHORIZED |
DUPLICATE |
CREDIT NOT PROCESSED |
PAID BY OTHER MEANS |
RECURRING |
NEGATIVE BALANCE |
CANCELLED RETURNED MERCHANDISE SERVICE |
OTHER |
Standard resolution status mapping
When submitting a resolution value, align your internal resolution statuses with SoFi Tech Solutions' standard values. Use the table below to map 3rd-party dispute processor resolution values to SoFi Tech Solutions terminology.
| 3rd-party values | To SoFi Tech Solutions |
|---|---|
WRITE OFF | |
CHARGEBACK | |
CUSTOMER LOSS | |
MERCHANT CREDIT | |
WIP or RESOLUTION STATUS NOT POSTED |
Updated 25 days ago

