Skip to main content
The Rule Engine processes data through two channels: real-time API calls and scheduled batch file uploads. Your choice depends on your source system’s capabilities and the latency your loyalty program requires.

Upload methods

API integration (real-time)

Connect your system directly to Loyalife’s Transaction API to submit events as they occur. The Rule Engine evaluates and awards points immediately after each submission. When to use API integration:
  • Your program requires near-instant point updates after a purchase
  • Members expect to see their balance update right after a transaction
  • Your platform already has API capabilities
See the Insert Transaction API for the request format and field reference.

Batch processing (file upload)

Data accumulates over a defined period and is processed in bulk at scheduled intervals. Files are transferred via SFTP to the Loyalife server. When to use batch processing:
  • Your source system already exports transaction logs on a schedule (end of day, hourly, etc.)
  • Near-real-time updates are not required by your program
  • You are migrating a large historical transaction dataset

SFTP file upload

1

Obtain SFTP credentials

Request your program-specific SFTP credentials from your Loyalife administrator. These credentials are unique per program.
2

Connect via VPN

SFTP access is VPN-restricted. Connect to your approved VPN before attempting the SFTP connection.
3

Upload to the correct directory

Connect to the SFTP server and upload your file to the appropriate directory based on file type:
File typeUpload path
Transaction file (TXN)upload/TXN
Customer profile data (CPD)upload/CPD
Bonus file (BNS)upload/BNS
Card reference data (CRD)upload/CRD
4

Monitor processing

Processing begins automatically after upload. Check the Logs report in Reports & Analytics for upload status, processed record count, and any rejected rows.
Files uploaded to the wrong directory are not processed. Always use the correct path for each file type. SFTP access requires an active VPN connection — uploads will fail if VPN is not connected.

File types and formats

Loyalife supports four file types for batch data ingestion. All files are CSV or pipe-delimited depending on program configuration.

TXN — transaction file

The TXN file submits purchase or activity transactions for points evaluation by the Rule Engine. The columns included in a TXN file are fully customisable — whatever fields the client’s source system can export are defined as global attributes or custom attributes in Loyalife, and those values are ingested and stored against each transaction.
Download the sample TXN file from the Rule Engine section in Loyalife before building your upload pipeline. It reflects the exact columns configured for your program.

CPD — customer profile data file

The CPD file updates member profile information — used when member data is managed in an external system and synced to Loyalife in bulk. The fields included are customisable per program: any member attributes the client wants to maintain in Loyalife are defined as global or custom attributes, and the CPD file carries those values in on each sync.

BNS — bonus file

The BNS file credits bonus points outside of the standard transaction-to-rule evaluation flow. It is used for manual bonus awards, promotional grants, or migration of historical balances. Like other file types, the columns are configurable and map to the attributes defined for your program.
BNS entries bypass the Rule Engine — points are credited directly without evaluating IF/THEN conditions. Use BNS for direct awards only; use TXN files when you want the Rule Engine to calculate the correct point amount from a transaction.BNS file uploads post as Credit By Bonus entries on the member’s ledger. If the BNS file is used for a balance migration or inbound transfer from an external programme, the entries may alternatively appear as Credit Transfer. Both are filterable in Transactional reports under Reports & Analytics → Transaction Category.

CRD — card reference data file

The CRD file links cards and supplementary accounts to a primary member. It is used in banking programs where a single member account has multiple cards — for example, a primary cardholder with one or more supplementary cards for family members.
CRD is relevant for programs where transactions arrive tagged with a card identifier rather than the primary member’s Relation Reference. Loyalife uses the CRD mapping to resolve the correct member account when evaluating rules and posting points. Without a CRD entry, transactions submitted with an unrecognised card identifier are rejected.
Once loaded, linked cards are visible in the member’s profile under Account Info → Linked Accounts & Cards. Aggregate attributes (Monthly Spend Sum, Transaction Count, etc.) accumulate across all cards linked to the same primary account.

Pre-processing layer

For programs that receive data files from external systems (banks, ERP platforms, payment networks), Loyalife’s pre-processing layer transforms files before ingestion. Pre-processing runs between SFTP upload and Rule Engine evaluation. Any fields a client wants to share — across any file type — are defined as global attributes or custom attributes in Loyalife. The pre-processing layer normalises the incoming file so those fields are correctly structured and can be pushed into Loyalife, where they are stored against the matching member or transaction attribute. This means the client’s source file does not need to match Loyalife’s internal format exactly — the pre-processing configuration handles the mapping. Typical transformations applied during pre-processing include date format normalisation, column merging, header stripping, and field trimming. The specific transformations are configured per program during onboarding based on the client’s source file structure.

Multi-program routing (BIN-based)

For programs receiving a single file containing records for multiple loyalty programs (common in banking / card programs), the pre-processing layer can route records to the correct program using a BIN (Bank Identification Number) or equivalent routing key. Each routing key maps to exactly one program. Records with an unrecognised routing key are written to a reject file rather than ingested into any program.

File validation

Validation happens at two levels: the file as a whole, and then each row individually.

File-level validation

These checks run before any rows are processed. A failure here rejects the entire file:
ValidationErrorFix
File is not emptyFile should not be emptyConfirm the export from your source system produced records
File has at least one data rowFile must contain at least one recordRemove header-only files; ensure data rows are present below the header
Column headers match the expected templateInvalid file format: Missing required headers / Invalid file format: Found unexpected headersRe-export using the sample file from the Rule Engine section; do not rename or reorder columns
File is CSV or pipe-delimitedOnly CSV files are acceptedConvert the file to CSV or the pipe-delimited format configured for your program
File name does not exceed 50 charactersFile is ignored by the processorShorten the filename before uploading
File encoding is UTF-8File may process incorrectly or fail silentlySave the file as UTF-8 encoded; avoid opening and re-saving in Excel without specifying encoding

Row-level validation

Each row is validated independently. A failed row is rejected and logged; all other valid rows continue processing:
ValidationOutcome on failure
All mandatory fields presentRow rejected
Relation Reference exists in LoyalifeRow rejected
Transaction date is a valid format (YYYY-MM-DD or YYYY-MM-DD HH:MM:SS)Row rejected
Amount is a valid number (not empty, not text)Row rejected
Points value is a valid non-zero number (BNS files)Row rejected
Currency type is a recognised valueRow rejected
Duplicate transaction referenceRow skipped (deduplication)
Column count matches expected number of columnsRow rejected
Rejected rows do not prevent other valid rows from processing. The rejection count and per-row error messages appear in the Logs report.

Complete error reference

File-level errors (entire file rejected):
Error messageCauseFix
Invalid file format: Missing required headersOne or more expected column headers are absentUse the sample file template; do not remove or rename columns
Invalid file format: Found unexpected headersFile has extra columns not in the templateRemove any added columns; match the template exactly
Invalid file format: Please use the sample file formatGeneral header mismatchRe-download and re-use the sample file
File should not be emptyFile contains no dataConfirm the source export produced records
Column count mismatchA row has more or fewer columns than the header definesCheck for stray commas or missing delimiters; wrap text fields containing commas in double quotes
Only CSV files are acceptedFile is not a supported formatConvert to CSV or pipe-delimited format
Row-level errors (individual row rejected):
Error messageCauseFix
Member not foundRelation Reference in the row does not match any enrolled memberVerify member IDs against the Members list; re-export from source if out of sync
Missing mandatory fieldA required column is empty for this rowFill in the missing value or remove the row
Invalid date formatTransaction date is not in YYYY-MM-DD or YYYY-MM-DD HH:MM:SS formatCorrect the date column; confirm pre-processing is applied if source uses a different format
Date & Time format should be YYYY-MM-DD HH:MM:SSCombined timestamp column has incorrect formatEnsure date and time columns are merged correctly; check pre-processing configuration
Amount must be a valid numberTransaction amount is empty, contains text, or is non-numericClean the amount column; remove currency symbols, spaces, or commas used as thousands separators
Points must be a valid numberPoints value in a BNS row is empty or non-numericCorrect the bonus amount column
Points cannot be zeroBNS row has a zero bonus amountRemove zero-value rows or correct the amount
Invalid currency typeCURRENCY_TYPE value is not MOKAFAA or CASHBACKUse only the accepted currency type values for your program
Duplicate transaction referenceA transaction with this reference was already processedRemove duplicate rows; use unique reference IDs per transaction
Comma in text fieldA CSV field contains an unquoted commaWrap fields containing commas in double quotes: "Test transaction, bonus"
Processing errors (file fails during backend processing):
Error messageCauseFix
Error in processing fileA technical error occurred during file processingRetry the upload; if the error persists, contact your Loyalife administrator
File processing failed completely due to technical error in the databaseDatabase-level failure during ingestionContact your Loyalife administrator — this requires investigation on the backend
The log file is no longer available for downloadThe error log has been automatically deleted per the program’s report retention settingsDownload error logs promptly after upload; check program retention period settings

Rule evaluation on batch files

After validation, each accepted row is evaluated against all active rule groups, following the same logic as real-time API transactions:
  1. Member’s segment membership is checked against each rule group’s linked segment
  2. IF conditions are evaluated against the transaction’s attributes
  3. Matching rules apply their THEN reward
  4. Points are posted to the member’s account
  5. Tier re-evaluation is triggered for the member

Error file delivery (SFTP return)

After processing, Loyalife can automatically deliver the error file (rows that failed validation) back to the client’s SFTP server. This enables fully automated pipelines where the client system receives rejected rows without accessing the Loyalife UI. This feature is configured per program and supports selective file types (e.g., only CPD and TXN error files, not BNS). Error files are placed in the client’s designated inbound SFTP path. The file naming convention mirrors the input file with a suffix indicating it is a rejection report.
Error file delivery to client SFTP is enabled by the Loyalife operations team during program setup. It is not available as a self-service toggle in the admin UI.

Monitoring uploads

Go to Reports & Analytics → Data Exports → Logs to see:
ColumnDescription
Upload timestampWhen the file was received
File nameThe original filename
Total rowsTotal records in the file
ProcessedSuccessfully evaluated records
RejectedRows that failed validation
StatusCompleted, Processing, Failed
Click any upload entry to see per-row rejection details, including the exact error message for each rejected row.

Troubleshooting

File uploaded but no points were awarded.
  • Check the Logs report for the file’s processing status.
  • Review the rejection count — if all rows were rejected, look at the error messages.
  • Verify Relation References in the file match enrolled members in Loyalife.
  • Confirm active rule groups exist for the members and transaction types in the file.
SFTP connection refused.
  • Confirm you are connected to the approved VPN.
  • Verify credentials are correct and have not expired.
  • Contact your Loyalife administrator to check SFTP server status.
Processing shows 0 records processed.
  • Verify the file was uploaded to the correct directory for its type (upload/TXN, upload/CPD, upload/BNS, upload/CRD).
  • Check file encoding — Loyalife expects UTF-8 encoded files.
  • Ensure the first row is the header row and that column names match the configured template exactly.
Not receiving upload status notifications.
  • Loyalife can send email notifications when a CPD, TXN, or BNS file finishes processing. The Super Admin is always notified. Additional email addresses can be added under Program Settings → Notifications. Contact your Loyalife administrator to configure this.