Questions
1. What is RFO (Response File Output)?
1.1. Definition
1.2. Usage
1.3. Key Considerations
2. What is AFD (Active File Delivery)?
2.1. Definition
2.2. Usage
2.3. Key Considerations
3. Why do RFO and AFD both exist today?
3.1. When did the RFO auto-enrollment change start, and what exactly changed?
3.2. Will new merchants receive RFO files?
3.3. Can AFD fully replace RFO technically?
4. Why is CSG Forte moving away from RFO?
4.1. Are new merchants automatically enrolled in RFO today?
4.2. What are the differences between RFO and AFD?
5. Do legacy merchants still receive RFO files?
6. Will migration from RFO to AFD happen automatically?
7. How does RFO data map to AFD?
8. What should be expected during the transition from RFO to AFD?
9. What information can AFD reports include?
10. How are AFD reports delivered?
11. Who should be contacted if there are questions about reporting files or notice a delivery issue?
1. What is RFO (Response File Output)? |
RFO is a legacy file‑based reporting system, it generates batch “S‑files” that contain:
- Credit card (CC) settlements
- ACH settlements (funded, unfunded, rejected)
- ACH NOC (Notice of Change) records
1.2. Usage |
|
|
- Core systems process and settle transactions.
- SQL jobs write settlement and NOC data into RFO output queues.
- The RFO2 service (the internal application that implements RFO):
- Reads the queues into work queues.
- Groups records (mainly by transmitter).
- Generates S‑files using fixed NACHA‑style layouts.
- Files are dropped into partner/merchant FTP (File Transfer Protocol) directories.
- Success and errors are logged in log/error queues.
1.3. Key considerations |
|
|
- Uses fixed, hard‑coded S‑file layouts.
- Still supported but considered legacy: inflexible and capacity‑heavy.
2. What is AFD (Active File Delivery)? |
|
|
Active File Delivery is a concept used in enterprise systems for automating and securely managing file transfers between systems. AFD is the modern, configurable file‑delivery engine in Dex:
- Generates and delivers reporting files based on configurable specifications defined in Dex.
- Delivers reporting files automatically to the merchant
- Ensures delivery (with retries, logging, alerts)
2.2. Usage |
|
|
Both partners and merchants can use AFD:
- Partner‑level jobs: one set of files covering multiple merchants under a partner.
- Merchant‑level jobs: one or more files per MID.
Note: New implementations are generally built directly on AFD and/or AutoDaily, not RFO.
AFD is used for:
- Generate reports using received and settled transaction data.
- Apply an AFD language (fields + functions) to build:
- Headers, detail lines, footers
- Dynamic file names and email subjects
- Totals, counts, formatted dates and amounts
- Deliver files via:
- SFTP (SSH File Transfer Protocol)/FTP; and/or
2.3. Key considerations |
|
|
AFD jobs are configured entirely in the Dex UI. For each job define:
- MIDs/locations to be included.
- Time zone and whether data is Received‑based or Settled‑based.
- Filters (channels, payment methods, brands, statuses, etc.).
- File layout:
- Delimited (CSV, TAB, PIPE) or fixed width
- Column order and formatting
- Delivery addresses and/or transmitters.
- Schedule and whether to send files when there are no records.
3. Why do RFO and AFD both exist today? |
|
|
They coexist because:
- Some partners continue to rely on RFO S-files as originally auto-enrolled, with AFD implemented as a post-release solution.
- Migrating away from RFO requires coordination, testing, and sometimes partner projects.
- AFD is the strategic long-term replacement; however, migrations are executed on a partner-by-partner basis rather than enforced globally.
RFO is maintained for:
- Cases where no safe AFD replacement is ready yet.
- Specific partners where RFO remains the least‑risk option for now.
3.1. When did the RFO auto-enrollment change start, and what exactly changed? |
|
|
In November 2025, CSG Forte changed the default setup for newly onboarded merchants so that RFO files are no longer automatically enabled.
- Before: every new MID was automatically configured with RFO; S‑files were generated daily by default.
- After: RFO remains active for pre‑change Merchant IDs (MID), but new MIDs do not get RFO by default.
This change was made to reduce unnecessary file generation and to align new reporting setups with more current reporting options. Merchants and partners that were already using RFO before that change may continue receiving RFO files until their reporting setup is reviewed and updated, if needed.
3.2. Will new merchants receive RFO files? |
|
|
In some cases, RFO may continue to be used temporarily for existing business needs. However, AFD is the preferred reporting solution going forward, and new reporting setups are generally evaluated with AFD in mind.
3.3. Can AFD fully replace RFO technically? |
|
|
In most cases, yes, the same settlement and transaction data used in RFO S‑files is available as AFD fields:
AFD Can | AFD Can |
Rebuild S‑file‑like layouts or offer richer CSV/Delimited formats with extra fields. |
|
The main limitations are external consumer systems: when a partner’s internal systems are tightly coded to RFO S‑files, migration requires:
- Maintaining backward‑compatible AFD outputs, or
- Coordinated changes and testing on their side before RFO is fully retired.
4. Why is CSG Forte moving away from RFO? |
|
|
- Waste and efficiency: In some cases, RFO files continued to be generated even when they were no longer being actively used, which increased operational overhead.
- Limited flexibility: RFO uses fixed file layouts, which can make it harder to adapt reports as reporting needs change.
- Modernization strategy: CSG Forte is working to transition reporting toward more modern solutions, primarily AFD and AutoDaily, where appropriate.
AFD can deliver equivalent or better data with richer ownership and configuration.
4.1. Are new merchants automatically enrolled in RFO today? |
|
|
No. New MIDs by default use other reporting mechanisms (typically AFD and/or AutoDaily) when reporting is required.
4.2. What are the differences between RFO and AFD? |
|
|
| Area | RFO (Response File Output) | AFD (Active File Delivery) |
| Status | Legacy | Strategic / current |
| Configuration | Backend / DevOps; ticket‑driven | Dex UI (Active File Delivery tab) |
| File Formats | Fixed S‑file layouts | Configurable (CSV, TAB, PIPE, fixed width) |
| Flexibility | Low | High |
| Multiple jobs | Limited / not typical | Common - multiple jobs per partner/merchant |
| Default for new MIDs | Disabled (post‑Nov 2025) | BillPay by default; available upon request for other services |
5. Do legacy merchants still receive RFO files? |
|
|
Yes. Merchants and partners with existing MIDs from before the policy change continue to receive RFO S‑files until RFO is explicitly disabled for their transmitter.
6. Will migration from RFO to AFD happen automatically? |
|
|
No. Migration from RFO to AFD does not happen automatically for everyone at the same time. Each migration is reviewed based on business needs and readiness for transition. Migration is typically evaluated when a business is still using RFO, when reporting needs change, or when it makes sense to move to a more flexible reporting solution.
7. How does RFO data map to AFD? |
|
|
In most cases, the same underlying transaction and settlement data available through RFO can also be supported through AFD. The exact report format, file structure, and delivery setup may vary depending on business needs, but AFD can generally be designed to align closely with existing reporting requirements while also supporting more flexible reporting options
8. What should be expected during the transition from RFO to AFD? |
|
|
The transition typically includes reviewing current reporting needs, preparing the AFD version of the report, testing the output, confirming readiness, and then moving to the new delivery method with support from CSG Forte teams.
9. What information can AFD reports include? |
|
|
AFD reports can include transaction and settlement information, depending on the reporting needs being supported. They may provide transaction-level detail as well as settlement-related data, and can be designed for a single merchant or for multiple merchants grouped under a partner.
Depending on the report design, AFD output may include items such as individual transaction details, settlement activity, summary totals, record counts, formatted dates, and formatted amounts. Reports can also be structured with headers, detail lines, and footers to support different reporting and reconciliation needs.
AFD reports may reflect different views of activity, including received and settled transaction data, depending on how the report is intended to be used. The exact fields, organization, and level of detail can vary based on the report design and business requirements.
In general, AFD is intended to provide a more flexible reporting option than legacy RFO files, allowing report content and format to be aligned more closely with business needs.
10. How are AFD reports delivered? |
|
|
AFD supports delivery via:
- Email attaching the file to messages sent to configured To/CC/BCC recipients.
- SFTP/FTP writing the file to configure directories using transmitters.
Note: Jobs can be configured to send even when empty, if merchants want confirmation emails with no data.
11. Who should be contacted if there are questions about reporting files or notice a delivery issue? |
|
|
If there are questions about the reporting files or notice a delivery issue, please contact CSG Forte Customer Support at customerservice@forte.net or 866-290-5400, Option 1, Monday through Friday, 7:00 AM to 7:00 PM CST.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article