White Paper on SIT-BAC
Version 3
Standard Information Transfer – for Buyer Call Compliance
Executive Summary
SIT-BAC is a proposed free and open source standard that allows for companies using ping/post, direct post, as well as all existing real-time delivery methods to both be compliant with the FCC new One-To-One requirement and still continue using their existing systems. The SIT-BAC standard also can be fully decentralized allowing for companies to operate private and proprietary versions of SIT-BAC that do not require data being sent to a central server.
It should be noted that SIT-BAC is in itself not a product or service but rather a common framework that can be adopted by companies in the industry. The proponents of SIT-BAC plan on releasing a public and free version of SIT-BAC that can be used alongside privately hosted versions.
Version 3 Updates
After receiving feedback from various stakeholders a key point emerged around the risk of a single platform maintaining the compliance standard and the risk of that service going down. In Version 3 updates, the white paper expands on the SIT-BAC standard and outlines how private versions of SIT-BAC could be hosted and maintained by individual companies or Lead Management Systems (LMS) for a fully distributed model. This model would allow companies to all interact using the common SIT-BAC framework without having to rely on any centralized solution.
FCC Ruling and Problem
On Dec 13th the FCC published the final rule aimed at closing what they call the “Lead Generator Loophole” the FCC proposed to do this by mandating a new One-To-One (“OTO”) requirement that requires lead generation websites to display and the consumer actively select the single (or possibly multiple) entities they wish to give their consent to be contacted to. The FCC also explicitly ruled that marketing partner lists, which are currently widely used, that display multiple entities are inadequate in terms of consent under the TCPA regulations.
The FCC has given the industry 12 months to comply with this ruling and for lead generation websites to start being OTO compliant. See the full decision here.
This white paper outlines an open source and free to use technical solution, the SIT-BAC (Standard Information Transfer – for Buyer Call Compliance) Standard for how lead generators, marketplaces and and buyers can continue operating and selling leads, including using ping/post or direct post systems while still remaining compliant with the OTO requirement. The SIT-BAC standard works by dynamically inserting the correct entity that will be contacting the consumer into the TCPA language prior to the form submission. The SIT-BAC Standard also allows for staggered rollout during the implementation period and does not fundamentally change how existing ping/post or direct post systems operate.
Why SIT-BAC
The SIT-BAC Standard has a number of advantages to meeting the OTO requirement set forth by the FCC.
- SIT-BAC allows for FCC and TCPA compliance with minimal changes and no additional cost.
- SIT-BAC is intended to be free and open source avoiding the segmentation of the industry based on a number of proprietary paid to use solutions.
- SIT-BAC allows for a private decentralized version to be hosted and run, avoiding the risk of any centralized solution or centralized server failure.
- SIT-BAC allows for a staggered rollout and is both forward and backward compatible.
- SIT-BAC requires minimal changes to process and allows for the continued use of the ping/post frameworks as well as continued use of custom and third party ping/post and direct post platforms.
- SIT-BAC allows lead generators to post leads that were post rejected to secondary or tertiary buyers while still maintaining OTO compliance.
- SIT-BAC allows lead generators the ability to sell shared leads or list multiple end buyers if desired.
- SIT-BAC is highly flexible in nature and allows lead generators the ability to design, build, and modify their websites as needed without locking them into a certain understanding of the OTO ruling or dictating a specific approach to compliance.
- SIT-BAC is non-competitive with platforms, lead generators or third party certifications or audit tools allowing for industry adoption.
- SIT-BAC is already backed by a number of industry players and major ping/post platforms.
How SIT-BAC Works
The SIT-BAC standard takes a minimalist’s approach to solving the FCC requirement and emphasizes flexibility and ease of use. The SIT-BAC standard consists of just 4 APIs calls. Two API calls will be used by the website collecting, 1 by the lead management platform and 1 by the end buyer or the entity bidding on behalf of the end buyer.
A high level and overly simplified explanation of the SIT-BAC standard would be as follows.
- A consumer starts filling out an online quote form or lead form.
- Once the consumer has entered enough information to populate all of the fields required for a ping, the website calls the SIT-BAC api and requests a PingID.
- The SIT-BAC server responds with a PingID in the form of a URL with a unique pingid. This url pingid indicates with SIT-BAC endpoint the end buyer will eventually call.
- The website then sends the ping including the PingID to its Lead Management System (“LMS”) to be pinged out as a normal ping but now includes a field for PingID.
- In the case that the lead generator is selling to a marketplace or aggregator the aggregator simply forwards the ping along with the PingID in the same way they currently do.
- An end buyer wishing to place a bid then takes the PingID, calls the SIT-BAC API endpoint listed in the PingID, submitting both the PingID and TCPA entity that it would like displayed on the website. The SIT-BAC API responds back with a ClaimID.
- The end buyer responds back to the ping with its bid price as usual and the ClaimID.
- In the case that the ping was passed through a marketplace or aggregator, that entry simply passes back the ClaimID sent to it to the lead generator along with the buyer’s bid.
- The lead generator (or the lead generator’s LMS) selects the winner of the ping auction as it currently does, however now each bid also has an associated ClaimID.
- The lead generator submits the winning ClaimID along with potential backup ClaimIDs to the SIT-BAC API.
- The website calls the SIT-BAC API to pull down the TCPA entity associated with the winning bid when the consumer reaches the final step of the form where the correct TCPA entity needs to be named for OTO compliance.
- The website can optionally pull down the second or third or additional TCPA entities in the case the first entity post rejects the lead. The website operator has maximum flexibility in determining how the website operates (e.g. the website might choose to display all of the entities prior to the submission requiring the user to check each off each one, or hold the user on the page in case the first entity post rejects or display the entity or entities on the next page)
*UPDATED Decentralized setup and configuration in the event of server failure.
It was noted as a risk by several stakeholders of the inherent risk of a centralized platform. To mitigate this risk this section explains how SIT-BAC should be configured to allow for decentralized systems to host private versions of SIT-BAC.
Most importantly each private version of SIT-BAC including the default public version would send the PingID in the format of the url of the endpoint to call to submit a TCPA Entity. (e.g. LeadsPedia might pass (leadsdpedia.com/pingid/1234) as the PingID), this would allow an end buyer wishing to submit a TCPA entity to call the correct SIT-BAC server to submit the entity and would allow the hosting LMS (in this case Leadspedia) to de-dupe redundant TCPA entity submissions so the same company is not listed twice on the website.
Furthermore this fully distributed model would mean that no data is shared with any other SIT-BAC server, there is no centralized platform, and each platform or company wishing to host their own version would be responsible for costs and upkeep.
To help maintain industry access, a free and public version could also be maintained as a backup solution.
In the event of any SIT-BAC outage, systems should revert to using plaintext transfer of the TCPA entity. While this has several obvious drawbacks including exposing client buyer lists, allowing for the potential adulteration of the TCPA entity text by middle players and removing the safeguard of verification it also allows for the uninterrupted transfer of the TCPA entity for OTO compliance. Each private version of SIT-BAC should be configured to accept plain text TCPA entities along with ClaimIDs to allow for continued operations during an outage.
Diagram of Simplified SIT-BAC flow
Combined Diagram of SIT-BAC (Ping & Ping Response)
Technical Diagram of the SIT-BAC Standard
How SIT-BAC will be administered
SIT-BAC is being spearheaded by the technical team from Blue Ink Digital however it will be maintained in a separate entity set up for the purpose of building and maintaining the default SIT-BAC standard.
Private versions of SIT-BAC will be maintained by private companies, most often separate LMS platforms that wish to host their own versions. Each private version will be responsible for their own costs and upkeep of their version.
Blue Ink Digital will be one of the financial backers of the SIT-BAC standard but may also seek out corporate sponsors to help cover the cost of development and ongoing maintenance. A number of companies supporting the SIT-BAC standard have already expressed support, technical resources and financial backing. The codebase and technical renderings of the SIT-BAC API will be publicly available to ensure transparency with the common standard.
FAQ Section
Why offer a default public and private hosting of SIT-BAC servers?
After interviews with all of the major LMS platforms, 20+ buyers and lead generators it was clear that a fully centralized solution would not be feasible or desirable for a number of companies. However a number of companies also expressed that they would not have the ability to create/ host a version of SIT-BAC themselves and would appreciate a public solution.
The companies against a centralized solution would strongly prefer not to have to reply on another platform for compliance. To accomplish this a decentralized version is being promoted to allow those companies the ability to create and or host their own version that is compatible with a public and free to you version.
Why Free and Open Source?
The main goal is to allow ping/post and direct post operations to continue and companies relying on those systems to continue operating. The goal of the SIT-BAC standard is to allow the lead industry to continue with minimal disruptions and still be compliant. Further, the OTO requirement means that buyers, vendors, lead platforms and lead generators must all use a common standard to be able to communicate the correct entity to be dynamically displayed. Solutions aiming to make a profit risk, promoting a new system incompatible with ping/post, fracturing the industry and creating walled off solutions that prevent different platforms, buyers and lead generators from working together.
Who will be implementing the SIT-BAC APIs?
In practice lead generators will need to make changes to how their websites operate both by sending off a ping prior to a lead submission and by dynamically updating the TCPA text with the correct TCPA entity prior to the lead submission. Lead Management Platforms (LMS) (e.g. LeadsPedia, LeadProsper and Boberdoo as well as custom platforms) will in practice need to submit the ClaimIDs of the winning bidders to the correct SIT-BAC API. LMS’s will also need to support the API to submit the PingID and TCPA entity when bidding on behalf of a direct post buyer, a buyer with a delivery system that is not programmatic, or a buyer without a LMS system in place. Fortunately, this has already been discussed with the leading LMS systems and is only a minimal change and a number of the LMS platforms already support the SIT-BAC standard.
Why not just pass the buyer name back instead of using a PingID and ClaimID?
There are two advantages to passing back the ClaimID instead of a plain text buyer name. First, and most important is the ClaimID will be verified on the submission so the lead generator knows that it has not been altered. Second, passing a ClaimID masks the buyer names from all the middle entities in the same fashion ping/post does, alleviating concerns about disclosing client lists while still allowing for compliance. However nothing prevents a buyer from also submitting back the buyer name as well.
Who will need to create an account to use SIT-BAC?
- Lead Generators will need to create a free account in order to create PingIDs and submit the winning ClaimIDs from the public version of SIT-BAC. Private hosted versions may have their own signup process.
- End buyers or the Lead Management Systems that they use will need to create a free account to submit TCPA entities.
Who WILL NOT need to create an account to use SIT-BAC?
- Aggregators, Marketplaces and other resellers will not need to create an account since they will not be generating leads nor will they be the end buyers. These entities simply need to pass along the new fields as they are passed to them.
- End buyers using a LMS that already supports SIT-BAC or hosts its own version of SIT-BAC may not need to sign up for an account if the LMS submits the required TCPA entity name on their behalf.
What if no buyer submits a TCPA entity or the winning bidder does not submit a TCPA entity?
Part of the beauty of the SIT-BAC standard is that it can be used with only partial adoption. In the case that no buyer submits a TCPA entirety or the winning bidder does not submit a TCPA entity the website can use a default value (this can be a hyperlink to a marketing partner list as is commonly done today and is still compliant during the transition phase or any value the lead generator wishes to display). The default value can be programmed directly on the website or can be set up when creating a free account.
What if the OTO requirement is struck down by the courts after implementation?
In the case that the OTO requirement is relaxed or no longer imposed on the lead generation industry anyone using the SIT-BAC Standard can simply ignore the added fields since SIT-BAC does not fundamentally change the workings of pings post. No further technical changes would be needed.
How can I get involved or support the SIT-BAC standard?
If you would like to be involved, including technically involved in the development of the SIT-BAC standard or if you would simply like to add your company name to the list of supporters of the SIT-BAC standard, please reach out to greg@blueinkdigital.com.