FinCEN Renewed the Minnesota GTO. Banks Have Four Days to Restart $3,000 International Transfer Reporting.

TL;DR

• FinCEN renewed its Minnesota Geographic Targeting Order on August 7. It takes effect August 11, 2026 and runs through February 6, 2027.
• Banks and money transmitters with a branch, subsidiary, or office in Hennepin or Ramsey County must report qualifying international funds transfers of $3,000 or more.
• Reports are due by the end of the following month, must use FinCEN’s CSV template and FI Portal, and cannot be incomplete.
• The four-day implementation problem is data, not policy: beneficiary details, government-benefit source questions, exclusions, file controls, and evidence all need to work before the first covered transfer.

FinCEN just gave covered Minnesota banks and money transmitters four days to put a specialized international-transfer reporting process back into production.

The renewed Minnesota Geographic Targeting Order was issued August 7 and becomes effective August 11. It applies to qualifying transfers of $3,000 or more from customers with addresses in Hennepin or Ramsey County when the money—or the receiving financial institution—is outside the United States.

This is a renewal, not a surprise first edition. But treating it as a calendar extension would be a mistake. FinCEN also published revised FAQs that answer the operational questions most likely to break a filing: what counts as a partial government-benefit source, what happens when beneficiary data is missing, how to handle legal entities without birth dates, and whether incomplete reports are acceptable.

The short answer to that last one is no.

What the renewed FinCEN Minnesota GTO actually covers

A Covered Business is any bank, as defined by 31 CFR 1010.100(d), or money transmitter, as defined by 31 CFR 1010.100(ff)(5), with a branch, subsidiary, or office in Hennepin County or Ramsey County.

A transfer is reportable only when all applicable conditions are met. That is important: this is not a blanket report of every $3,000 international payment.

FinCEN’s August 7 announcement says the order is intended to help trace funds diverted from Minnesota government-benefit programs and laundered abroad. Treasury’s accompanying press release says the renewed requirements are otherwise unchanged from the prior order after incorporating a February 27 exemption for certain bank-originator categories.

That makes the implementation question sharper: can the institution prove every inclusion and exclusion in the table from data available at transaction time?

A policy that paraphrases the order is not that proof. The evidence is a rules specification, data map, tested population, exception queue, approved file, and transmission receipt.

The beneficiary-data problem is the real deadline

The order requires banks to report the transfer-record information already retained under 31 CFR 1020.410(a), plus additional fields. Those include the beneficiary’s name, address, date of birth, phone number, email address, and account number. Banks must also identify whether the transfer’s source includes funds from any federal, state, or local government contract or benefit program and, if so, whether the government payment went to an entity in which the originator has an ownership interest.

Money transmitters have a similar list, plus the source form—currency, check, card, or other—the transmission method, including convertible virtual currency, and a specific field for international hawala ledger entries settled using cash couriers.

Three details in the new FAQs deserve immediate procedure changes.

1. Partial government funding still means “yes”

FAQ 9 gives a concrete example: if a $3,000 transfer contains $1,500 from a government contract or benefit program and $1,500 from another source, the government-funds answer is yes. Employment income from a government job and federal or state tax refunds do not count as government contract or benefit payments for this question.

That distinction belongs in the frontline question, job aid, and quality-control test. “Are these government funds?” is too vague to produce consistent data.

2. Missing information can stop the transfer

FAQ 10 says a required report must contain all required information. If the covered business cannot collect it, FinCEN says the business may consider declining to perform the function that triggers the obligation.

FAQ 11 is more direct: partial reports will not be considered compliant. Completing the transfer first does not remove the duty to obtain and report every required field by the deadline.

This creates a decision that Compliance cannot leave to a call-center representative improvising at the counter. Payments, Product, Legal, and the BSA Officer need an approved rule for whether a transaction is held, rejected, or escalated when a required field is absent.

3. “Not applicable” is narrow

If a beneficiary or recipient is a legal person and therefore has no date of birth, FAQ 8 allows Not Applicable or NA. That is not general permission to fill missing fields with NA. The institution should restrict that value by field and entity type, then test for misuse before filing.

Reporting mechanics: build the control around the file

Covered businesses report through FinCEN’s Financial Industry Portal. The order directs filers to select Special Measures and use reference number FIN-65547-X3M6T. Files must follow FinCEN’s Minnesota Fraud GTO CSV template and naming convention:

FilerName_TransactionYearMonth_File#ofTotal#_MNGTO2026.csv

The first reporting period covers August 11 through August 31, with a September 30 due date. Later monthly files are due at the end of the next month. The order itself ends February 6, 2027, but the FAQ schedule includes a March 31 deadline for covered February activity.

A workable file-control chain should include:

1. Population extraction. Payments Data Engineering generates the full transfer population before applying exclusions.
2. Coverage logic. BSA Compliance approves each inclusion and exclusion rule, with citations to the order.
3. Field validation. Automated checks reject blank required fields, invalid dates, malformed email addresses, unsupported NA values, and inconsistent government-funds answers.
4. Source reconciliation. Operations reconciles the final report count and amount to the covered-transaction population, documenting every removed item.
5. Maker-checker approval. One person generates the file; another reviews totals, samples records back to source systems, and approves submission.
6. Portal evidence. The filer retains the submitted CSV, approval, portal receipt, validation output, and reconciliation under one reporting-period identifier.

Do not let the CSV become the system of record. It is an output. Investigators and testers need to trace every submitted value back to the customer, payment order, KYC record, or documented customer response that produced it.

The order requires retention of reports and related compliance records for five years from the last day the order is effective, including renewals. Records must remain reasonably accessible and available to FinCEN or another appropriate agency on request.

A GTO report and a SAR are different controls

The GTO does not replace ordinary transaction monitoring or SAR decisioning. FinCEN’s FAQs say it does not create a new or amended SAR obligation.

But preparing the GTO file may expose suspicious facts. Where an institution files a SAR related to a covered transaction, FinCEN requests Minnesota Fraud GTO in field 2, Filing Institution Note to FinCEN, and in the narrative.

That keyword should be added to:

• the SAR procedure and analyst job aid;
• the case-management disposition menu;
• SAR quality-assurance rules;
• training examples for investigators; and
• any reporting logic that links a GTO record to a related case.

This is also a useful cross-platform test. Can an investigator start with a GTO file row and retrieve the transfer, customer profile, government-funds response, monitoring alerts, case disposition, and any SAR? If those records require five manual searches and a spreadsheet maintained by one analyst, the process is fragile.

For adjacent design work, the site’s FinCEN student-aid fraud monitoring breakdown shows how to translate a government-benefit typology into data tests, while the Section 314(b) fraud workflow covers cross-institution information sharing when its requirements are met.

The four-day implementation checklist

August 7: confirm scope and ownership

The BSA Officer should identify every branch, subsidiary, office, agent, and money-transmission operation in the two counties. The order requires a covered business to transmit it to agents in the covered area and to its CEO or similarly acting manager.

Open one regulatory-change record with named owners for scope, payment logic, KYC data, customer prompts, file generation, portal access, SAR procedures, training, testing, and evidence retention.

August 8: test the data

Pull a representative sample of international transfers at and above $3,000. Trace customer address, entity status, BSA-regulated-financial-institution status, beneficiary geography, receiving-bank geography, beneficiary fields, and source-of-funds questions from source to proposed file.

Log every missing or transformed field. Do not close a gap because the data “exists somewhere.” It must be available to the control that determines coverage or fills the report.

August 9: run an end-to-end dry file

Apply the coverage rules, generate FinCEN’s CSV, validate required fields, reconcile totals, and simulate maker-checker approval. Confirm FI Portal access now; an unapproved account discovered on the submission date is an avoidable failure.

August 10: approve customer and exception handling

Legal, BSA Compliance, and Payments Operations should approve scripts and workflow for collecting additional information. Define who can release, decline, or escalate a transfer when required data is missing or implausible. The FAQs permit reliance on customer-provided information unless known facts reasonably call its reliability into question.

August 11: activate and monitor

Turn on the production rule, confirm the first qualifying and excluded transactions behave as designed, and review exceptions daily during the opening week. Save screenshots, query results, approvals, and test records as implementation evidence.

What good closure evidence looks like

By the first filing, the regulatory-change record should contain:

• the signed scope assessment;
• order-to-rule traceability matrix;
• data lineage for every reported field;
• approved customer questions and exception procedure;
• FI Portal access evidence;
• dry-run and production validation results;
• population-to-file reconciliation;
• maker-checker approval and portal receipt;
• updated SAR keyword instructions;
• training completion; and
• a second-line test that samples both included and excluded transfers.

The last item catches the quiet failure mode: a clean report file produced from an incomplete population. Testing only submitted rows proves formatting, not completeness.

FinCEN’s renewed Minnesota GTO is geographically narrow, but its operational demand is exact. Covered institutions have to identify the right transfers, obtain nonstandard beneficiary and source-of-funds data, file complete monthly records, preserve the evidence, and keep SAR decisioning separate—all starting August 11.

If the review creates data, procedure, training, and testing gaps, put each one in the Issues Management Tracker & Template with a named owner, due date, validation step, and closure artifact.

Sources

• FinCEN: Minnesota Geographic Targeting Order, August 7, 2026
• FinCEN: Minnesota GTO Frequently Asked Questions, August 7, 2026
• FinCEN: Renewal announcement
• U.S. Treasury: Treasury Continues to Follow the Money in Minnesota
• FinCEN: Minnesota Fraud GTO submission template