A Background Screening Provider Connects Employer Hiring Systems to Its Screening Platform With Files.com SFTP

A background screening provider is a consumer reporting agency: employers send it applicant data, it runs criminal history searches, verifications, driving records, and drug testing, and it returns a screening report the employer can hire on.

The company's pitch to employers is integration. Its platform embeds with a client's HR and applicant tracking software so a screening order can be placed in one step, without re-keying candidates into a second system. That pitch puts the provider permanently between two systems it does not own: the client's hiring system on one side, and the screening platform its reports are produced on, on the other. Every order that crosses that gap is a file of candidate PII: names, Social Security numbers, dates of birth.

When a long-standing hospital client implemented Oracle HRIS and required an integrated screening data flow over SFTP, Files.com became the reusable SFTP integration layer the provider controls, removing manual handling without custom development for each client.

One Governed Path for Every Screening Order

For clients without a direct integration, the client exported candidate batches as CSV files and staff at the provider loaded each batch into the screening system by hand. The handling was manual on both sides, for every batch, from every client on that path.

The provider wanted one governed path for those files. The order files carry the most sensitive information the provider touches, and an order file that does not arrive is a background check that does not get processed. The provider wanted every screening order to reach the screening platform without a person moving it. As integration volume grew, one-off manual workarounds could not carry it.

A Client Mandate for SFTP With No Manual Handling

The requirement became a mandate when the hospital client implemented Oracle HRIS and required an integrated screening data flow, submitted over SFTP. Manual handling was off the table entirely.

A direct API integration is specific to one client's HRIS and depends on access the provider does not control. The provider wanted an integration layer it controls end to end, whatever hiring system the next client brings.

The layer had to sit between two systems the provider does not control, without custom development per client. It had to speak SFTP, because the client required it. It had to keep each client's data apart from every other client's, get order data into the screening system within the hour of its arrival, which was the bar the provider set for itself, and expire candidate PII on a schedule. And it had to be repeatable, because the next client integration could not be a new engineering project.

The provider selected Files.com to provide that controlled integration layer.

One Folder and One Credential per Client

Files.com became the integration layer between the client's hiring system and the provider's screening platform: a layer the provider controls end to end, whatever either endpoint offers.

The client's Oracle HRIS writes CSV order files, each carrying one or more candidates, over SFTP into a client-specific folder on the provider's Files.com site. Each counterparty gets its own credential, scoped to its own folder. The client's system has a dedicated SFTP user that can post order files and nothing else. The screening platform connects with its own account to collect them and manage the flow. Neither touches any other client's data, which is what makes a single intake site safe to share across every client the provider adds.

The screening platform polls the folder on a schedule and creates a background check order from each file it finds, putting order data in the system within the hour of arrival. Using Files.com Automations, each file is moved into a processed archive the moment the screening platform downloads it, so nothing is ever picked up twice.

That archive is the only copy of candidate PII living outside the screening system, so the provider put a Files.com retention policy on it. Archived files purge automatically after a set window, deliberately shorter than the company's internal log retention because the copy carries PII, with enough of a floor left for troubleshooting.

No More Manual, Within the Hour

With the Files.com workflow in production, the provider replaced manual batch handling with a repeatable integration pattern.

• Candidate data leaves the client's hiring system and arrives in the screening platform with nobody touching it. Orders are created within the hour a file lands.
• The client's mandate was met exactly as stated: no manual handling, over the protocol it required, and a long-standing relationship held through the client's HRIS change.
• Candidate PII has one path in and one copy outside the screening system, and that copy sits behind a scoped credential and deletes itself on policy.

The compounding result is larger than the first integration. Nothing in the design is specific to this client. The same structure is the template for any further client running a similar integration: a client-specific folder, a posting credential, the same automation and retention behavior. Adding the next one takes no new development.

The Integration Layer Is Now Theirs

The integration layer is the provider's own. What it built is a repeatable way to connect any employer's hiring system to its screening operation over SFTP, with no custom development for the next client.