What Data to Collect From Payment Partners Before Filing a FINTRAC EFTR

Before filing an Electronic Funds Transfer Report (EFTR), a Canadian MSB needs to know its role in the transfer, the time it initiated the transfer or received the instructions, the amount, currency and rate, whether SWIFT was used, and who the requester, any third party, the initiator, the receiver and the beneficiary were. Your own systems hold the requester and the instruction. Payout partners, correspondent providers and remittance networks often hold much of the beneficiary, receiver and payout information.

The FINTRAC EFTR required information is not one fixed list. It changes with the direction of the report and with each field's category, so the partner data you need changes too. Two kinds of data are involved:

• Regulatory fields: what FINTRAC's field instructions require in the applicable report.
• Internal operational fields: what you need to match partner records to your own transactions, show completeness and meet the deadline. These include partner references, payout status and data-request history.

This article covers how to obtain, validate and reconcile partner-supplied data before a report is prepared. Reportability rules, thresholds and aggregation are covered in the guide to FINTRAC EFTR reporting rules, and only the parts that drive data collection are repeated here.

Settle your reporting role before you ask a partner for anything

The fields that apply depend on whether your business is reporting an initiation or a final receipt. Under FINTRAC's EFT reporting guidance:

• Initiation is the first transmission of instructions for the transfer, made at the request of a person or entity.
• Final receipt is the receipt of instructions by the person or entity that is to make the remittance to a beneficiary.
• An intermediary does not file an EFTR for the transfer. It must keep records and pass on travel rule information.

EFTR obligations apply to financial entities, MSBs, foreign MSBs and casinos. A payout partner overseas, a processor in the middle, or a Canadian payment company in the chain may or may not be a FINTRAC reporting entity. That is a separate legal question. A partner's own regulatory filing, whether in Canada or elsewhere, does not discharge your reporting obligation for your role in the transfer.

Two rules from the guidance limit what you can hand off:

• A service provider can submit or correct an EFTR on your behalf, but you remain legally responsible for it.
• If an agent acts for you, the reports for its activities are yours.

The parties in a report are distinct, and partner files often merge them:

FINTRAC's guidance gives three business examples:

• An employee who requests a transfer for their employer is the requester, and the business is the third party.
• An owner or chief executive acting for the business makes the business the requester.
• An accountant acting for a business is the requester, and the business is the third party.

Family remittances need the same care. A relative receiving funds is the beneficiary. That relative is not automatically a third party, unless they are directing the transfer.

The questions to ask and record are set out in the guide to FINTRAC third-party determination requirements.

How field categories change what you must obtain

Every EFTR field falls into one of four categories, set out in Annex A of FINTRAC's EFTR field instructions. The category tells you how hard you have to work to obtain missing partner data.

Several practical consequences follow:

• The same field can change category with the report's direction. FINTRAC's guidance gives the requester's date of birth as the example: required on an initiation report, reasonable measures on a final receipt report. Requester name, address, occupation and identification follow the same pattern. On an outgoing transfer those details come from your own KYC. On an incoming transfer they have to come from the partner chain.
• Beneficiary details carry the opposite weight. FINTRAC's published EFTR validation rules reject an above-threshold final receipt report that has no beneficiary identification, where no regulatory exception is claimed. That makes the payout-side identity data the critical item when you are the receiver. On an initiation report, check each beneficiary field's category in the field instructions rather than assuming the same treatment.
• There is one narrow exception for aggregated reports. If the information for a mandatory field was not obtained at the time of the smaller transactions in an aggregated report, the field is treated as reasonable measures. The exception does not apply if any transaction in the report is $10,000 or more. FINTRAC describes it for mandatory fields only.
• Some fallbacks are prescribed. Where it is unknown whether the requester is a person or an entity, FINTRAC's instructions direct you to select "Entity", and the instructions apply the same rule to the beneficiary type. That fallback is for genuine uncertainty. It does not apply where records you already hold show the actual type. Similarly, a person with only one name is reported with the single name as the surname and "XXX" as the given name.
• Inapplicable fields are left blank. FINTRAC's instructions prohibit "N/A", "unknown" and placeholder characters. Never insert invented names, addresses or numbers to get past validation.

Partner-data collection matrix

The matrix shows where each category of information usually comes from and how it relates to FINTRAC's requirements. It is not a complete list of mandatory fields. Field status depends on the report's direction and on whether each field applies.

Threshold conversion is a separate step. For a foreign-currency transfer, you test the $10,000 threshold by converting the amount using the Bank of Canada exchange rate in effect at the time of the transaction. Where the Bank of Canada does not publish a rate, use the rate you establish in the normal course of business at that time. Your policies and procedures should describe that process. This conversion decides reportability; it does not replace the amount and currency reported. For historical transfers, keep the rate, its source and its date with the record, so the threshold decision can be re-performed later.

Residential status is narrower than it looks. A Canadian MSB does not determine residential status for every transfer. It needs it when it both initiates and finally receives the same transfer, for example when both the sender and the recipient are its clients. An FMSB needs it to decide whether its transfers are reportable at all. A client is "in Canada" when, for example, their address is in Canada, their identification was issued in Canada, or their banking or payment service is based in Canada, even while they are physically abroad. A client who is physically present at a Canadian MSB location is treated as in Canada. Where the counterparty is a partner's customer, the partner may hold the only address or identification that settles the question.

Wallet addresses and transaction hashes are not part of the fiat EFTR data set reviewed above. Where a transfer is funded or paid out in virtual currency, that information belongs to the separate virtual currency reporting and travel rule analysis. Within the EFT workflow it is only a link between the crypto and fiat legs, a split explained in the guide to crypto off-ramp reporting obligations.

Travel rule information is not the full EFTR data set

A partner can meet the travel rule and still leave you short for an EFTR. Under FINTRAC's travel rule guidance, an EFT you initiate must include:

• the originator's name, address and account or other reference number, if any
• the beneficiary's name and address
• the beneficiary's account or reference number, where applicable

When you receive an EFT, you must take reasonable measures to make sure that information is included, and to obtain it if it is missing. Your written, risk-based procedures must say when you allow, suspend or reject a transfer that still lacks it, and what follow-up applies. FINTRAC does not require automatic rejection.

Example (hypothetical). A Vancouver MSB is the final receiver of a $14,000 CAD transfer from an overseas provider. The message carries everything the travel rule requires for both parties. The MSB's EFTR still needs more:

• the beneficiary's identification, which the MSB collects when it pays out
• the initiator's identity as an institution
• the time the instructions arrived
• the SWIFT or non-SWIFT type
• any third party

None of these is guaranteed to be in the travel rule message. Travel rule compliance tells you the message was adequate to move the funds. It does not tell you the report is complete.

What to ask a payment or payout partner

The questions below suit a partner onboarding questionnaire or a data-sharing schedule. They are recommended governance measures. FINTRAC does not prescribe the content of partner agreements, response times or escalation terms.

Data held and data shared

• Which party fields does the partner capture for senders, beneficiaries and intermediaries? Which are in the routine feed, and which are available only on request?
• How does it distinguish individual from business beneficiaries, and can that flag be included in every record?
• What beneficiary identification does it collect at payout? Can it provide the type, number and issuing jurisdiction?
• Does it hold structured addresses, or free text only?

Matching and status

• Which reference links its record to your original instruction? Does that reference survive amendments and re-sends?
• What time zone are its timestamps in, and which event does each timestamp represent: received, released or paid?
• Can it distinguish pending, paid, rejected, returned and reversed transfers? Does it report status changes after the first file?

Change and correction

• How will it notify you before changing its file layout or field definitions?
• How are corrections to beneficiary details communicated, and do they carry the original reference?

Escalation and security

• Who answers urgent data requests, and within what internal service level?
• How are documents or additional data transmitted securely, and who at each organization may receive them?

Agreeing these points in writing turns ad hoc chasing into a defined process. An internal service level for partner responses is useful, but it never changes FINTRAC's filing deadline.

When partner data is incomplete: a decision workflow

1. Name the exact missing field. "Beneficiary details missing" is too vague to act on. "Beneficiary identifier number missing on a final receipt report" is something you can work with.
2. Confirm the direction and the field's category in the current field instructions.
3. Check your own systems and records first. For reasonable-measures fields, information you already hold must be reported, even if the partner did not send it.
4. Request it from the partner, citing its reference and your internal deadline.
5. Record each reasonable measure: the field, the request, its date, any response and the outcome. Do this wherever the field is reasonable measures, or falls under the aggregation exception.
6. Escalate mandatory gaps. A mandatory, mandatory-for-processing or applicable mandatory-if-applicable field cannot be left blank. Escalate to the compliance officer early enough to act within the deadline.
7. Document the reporting decision: what was filed, what was not available and why, and who approved it.
8. Track the residual risk. Note any late filing, any recurring partner gap, and whether the pattern points to a partner-level or control problem.

When the same partner repeatedly fails to supply required data, the issue goes beyond reporting. Recurring gaps can also affect your partner risk assessment. Missing data is not in itself suspicious, but where the circumstances around a transfer, together with other facts, give reasonable grounds to suspect money laundering, terrorist financing or sanctions evasion, a suspicious transaction report must be assessed separately. They are also a common source of the problems described in common FINTRAC report validation errors.

Reconciling records across partners

Each reportable transfer needs one reconciled record built from several sources:

• your original instruction and internal reference
• the partner's payout or receipt reference
• direction
• requester and beneficiary identifiers
• amount and currency
• timestamps
• final status

Hypothetical reconciliation. An MSB uses two payout partners. Partner A sends a daily file keyed on the MSB's own reference. Partner B uses its own reference, records times in its local time zone, and resends corrected rows without marking them as corrections.

The reconciliation:

• matches Partner B rows on amount, currency, beneficiary name and a one-hour time tolerance
• flags any row matching more than one instruction for manual review
• treats a later row with the same partner reference as a possible correction, not a new transfer
• converts all times to the MSB's reporting time zone before applying its 24-hour window

Exact matches on the MSB's own reference are accepted automatically. Matches built from amount, name and time are treated as lower-confidence and confirmed by a reviewer before they are relied on.

The consolidated view then shows something neither partner file could. Assume the MSB's documented 24-hour window runs from 00:00 to 23:59 Eastern time:

Both are initiations by the MSB, each is under $10,000, and together they total $10,500 within the same static window. Once the reviewer confirms that both go to the same beneficiary, the MSB knows the transfers are linked. They must be reported together in one initiation report aggregated on the beneficiary. Each partner's file, viewed alone, showed only one transfer below the threshold.

No regulation sets a reconciliation frequency. A cycle short enough to leave time to chase gaps before the five-business-day deadline is the practical test.

Illustrative internal data collection template

Illustrative internal data collection template: not an official FINTRAC form. All references are fictional.

Three columns do different jobs. The threshold test and reporting status record whether a report is required, which depends on FINTRAC's rules. Data completeness records whether you have what the report needs. Follow-up records the work still open. A partner's own data-quality flag does not decide whether a report is required.

The record columns hold references to secured records, not the personal information itself. That keeps the working file useful without spreading identity data further than it needs to go. The template tracks the process. FINTRAC's API technical documentation and the field instructions remain the authority for the report's actual structure. Once the data is complete, it is prepared for whichever channel you use, as compared in the guide to FINTRAC API and Web Reporting methods.

Timing and escalation

An EFTR must be submitted within five business days after the day you initiate the transfer, or the day you finally receive it. Partner data that arrives on day four leaves no time for review, and a late partner response does not extend the deadline.

The controls that protect the deadline are internal choices: request partner data when the transaction is processed rather than when it is found reportable, alert on missing required fields, set an internal data-complete target ahead of the filing date, name an owner for partner follow-up with an escalation path to the compliance officer, require reviewer approval, and track each report to FINTRAC's acknowledgement.

Where a mandatory gap cannot be closed before the deadline, the decision belongs to the compliance officer, and it should be documented. There is no sanctioned workaround such as filing with invented data. If the issue spans many transfers or partners, AML advisory support can help redesign the partner-data arrangement.

Two worked scenarios

Both scenarios are hypothetical.

Scenario 1: Outgoing remittance through a payout partner

A Toronto MSB initiates a $13,200 CAD transfer for an individual customer to a beneficiary in another country. The payout partner overseas is the receiver.

• Role: The MSB is the initiator and files an initiation report. Its own details go in the initiator fields, and the partner's details go in the receiver fields.
• Requester data: The requester's name, address, date of birth, occupation and identification apply on initiation. They come from the MSB's own KYC file, not the partner.
• Beneficiary data: The MSB's record holds the beneficiary's name and address from the customer. The partner later reports that it verified the beneficiary's identity at payout. For each beneficiary field, the MSB checks its category on an initiation report. Where a field is reasonable measures and the partner offers the data, the MSB obtains it and reports it.
• Partner classification: The partner's file classifies the beneficiary as a business, but the customer described a relative. The MSB investigates the conflict before filing, rather than choosing whichever source is convenient. Its own records already identify the beneficiary as an individual, so the "Entity" fallback for an unknown type does not apply.
• Third party: The customer confirms the funds are their own and nobody else is directing the transfer. The MSB records that third-party determination.
• Filing: The report is filed on day three, after review, and its acknowledgement is recorded. The partner's payout confirmation arrives on day six. It is stored for reconciliation, since the initiation is reportable whether or not the payout completes.

Scenario 2: Incoming transfer through two providers

An overseas bank initiates a €11,000 transfer for an overseas company. Instructions pass through a second payment provider to a Canadian MSB, which pays a Canadian individual. Converted at the Bank of Canada rate in effect at the time, the amount is above $10,000 CAD. The report states €11,000 as the amount, with euros as the currency.

• Role: The MSB finally receives the instructions and is to make the remittance, so it files a final receipt report. The overseas bank is the initiator. The second provider is reported as an additional sending party if the instructions passed through it.
• Timing: The transaction time is when the MSB received the instructions. The beneficiary's later collection of the funds does not set it.
• Requester data: The inbound message gives the company's name, address and an account reference. Requester details are reasonable measures on a final receipt report, so the MSB reports what it obtained or holds, and records what it asked for. Because the company is not the MSB's client, its source of funds is not something the MSB holds.
• Beneficiary data: The beneficiary is the MSB's own customer, so this data comes from the MSB's records, not the partners. The identification it verified at onboarding or payout is the information the validation rules expect on an above-threshold final receipt report.
• Residential status: The MSB did not initiate this transfer, so it does not need to determine residential status to decide whether the transfer is reportable.
• Reconciliation: The second provider's reference differs from the overseas bank's. The MSB links both to its internal record and keeps the original message, so the initiator details can be traced.

Controls and personal information safeguards

Partner data becomes reliable when it is managed as a controlled input: standard field definitions agreed with each partner, documented mappings from partner fields to report fields, notice before file layouts change, automated completeness checks, an exception queue with named owners, reviewer approval, and an audit trail from partner record to submitted report.

Beneficiary and requester data is sensitive personal information:

• Collect only what reporting, the travel rule and your own AML controls actually need. Applicable Canadian privacy law expects collection to be limited to identified purposes. Gathering more identity data than you use is not better compliance.
• Restrict and protect access. Limit access to people with a reporting role, and exchange documents only through secure channels.
• Leave out data FINTRAC says must not be reported, such as a Social Insurance Number.

Pre-filing checklist

• ☐ Reporting role (initiation or final receipt) confirmed, and intermediary transfers excluded
• ☐ Applicable fields and their categories identified for that direction
• ☐ Partner records matched to the instruction by reference, amount, currency and converted timestamp
• ☐ Requester, beneficiary and third-party information collected as applicable, with person/entity type confirmed
• ☐ Source-of-funds information from your own records captured for initiations, and residential status determined where the MSB or FMSB rules require it
• ☐ Foreign-currency amounts tested against the threshold at the Bank of Canada rate in effect, with the rate and source recorded
• ☐ Related transfers across partners checked for aggregation
• ☐ Missing fields classified, with partner requests and reasonable measures recorded
• ☐ Mandatory gaps resolved or escalated before the internal cutoff
• ☐ Required fields validated, with no placeholders
• ☐ Compliance review completed
• ☐ Submission acknowledgement and partner status recorded

Frequently asked questions

Can a partner's internal customer ID stand in for the beneficiary's identification?

Not where the identification fields apply. Those fields ask for the type of identifier, its number and the issuing jurisdiction of the document or information used to verify the person or entity. A partner's customer number describes its own system, not that identification. Use the internal ID as a reconciliation reference. Where identification fields apply to your report, request the identification details themselves. Whether they apply depends on the report's direction and the field's category.

Do we need copies of the beneficiary's identity documents from the partner?

Not for the EFTR. The report asks for details of the identification, such as the identifier type, number and jurisdiction of issue. It does not ask for an image of the document. Your own identity verification and record-keeping obligations for your clients are a separate matter, and they depend on how you verified the person. For a partner's customer, routinely collecting document images goes beyond what the report needs and adds privacy risk, so obtain the details the report requires.

What if a partner corrects beneficiary details after our report was accepted?

First decide whether your report was wrong. If the partner's correction shows that information you reported was inaccurate, the accepted report needs to be changed, through the process for correcting previously submitted FINTRAC reports. If the details simply changed afterwards, for example because the beneficiary moved, the report described the transfer accurately at the time, and the change belongs in your records rather than in the report.

Partner data rarely arrives report-ready. ComplyFactor provides a FINTRAC reporting workflow for mapping transaction data to report fields, validating completeness before submission, routing reports through controlled review and tracking acknowledgements, while reporting decisions stay with your compliance team.